WO2023131845A1 - Gestion basée sur un réseau d'une indication d'état d'une session de qualité d'expérience pendant un transfert conditionnel - Google Patents

Gestion basée sur un réseau d'une indication d'état d'une session de qualité d'expérience pendant un transfert conditionnel Download PDF

Info

Publication number
WO2023131845A1
WO2023131845A1 PCT/IB2022/062542 IB2022062542W WO2023131845A1 WO 2023131845 A1 WO2023131845 A1 WO 2023131845A1 IB 2022062542 W IB2022062542 W IB 2022062542W WO 2023131845 A1 WO2023131845 A1 WO 2023131845A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
cho
target node
qoe
handover
Prior art date
Application number
PCT/IB2022/062542
Other languages
English (en)
Inventor
Cecilia EKLÖF
Johan Rune
Luca LUNARDI
Ali PARICHEHREHTEROUJENI
Filip BARAC
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
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 (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Publication of WO2023131845A1 publication Critical patent/WO2023131845A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/34—Reselection control
    • H04W36/36—Reselection control by user or terminal equipment
    • H04W36/362—Conditional handover
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/02—Buffering or recovering information during reselection ; Modification of the traffic flow during hand-off
    • H04W36/023—Buffering or recovering information during reselection
    • H04W36/0235—Buffering or recovering information during reselection by transmitting sequence numbers, e.g. SN status transfer

Definitions

  • the present disclosure relates generally to communications, and more particularly to communication methods and related devices and nodes supporting wireless communications.
  • QoE measurements also referred to as “application layer measurements”
  • application layer measurements have been specified for LTE and UMTS and are being specified for NR in 3GPP release 17.
  • 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.
  • MTSI Mobility Telephony Service for IMS
  • QMC Quality of Experience Measurement Collection
  • QoE reports QoE reports
  • An application layer measurement configuration also called QoE measurement configuration or QoE configuration
  • QoE configuration that the RAN receives from the 0AM system or the CN is encapsulated in a transparent container, which is forwarded to a UE in a downlink RRC message.
  • An application layer measurement report (also called QoE report) that the UE Access Stratum (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
  • 3GPP 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. AR/VR and URLLC, of which at least VR seems to be covered in 3GPP 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 (in standard specifications typically referred to as application layer measurements) consists of a service type indication, an indication of an area in which the measurements are to be performed (denoted area scope), an IP address of the entity the collected measurement results (i.e. the QoE reports) should be sent to (often referred to as a MCE, spelled out as Measurement Collector Entity or Measurement Collection Entity, 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.
  • 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 QoE configuration and signaling-based QoE configuration.
  • the QoE configuration originates in the 0AM system or some other administrational entity, e.g. dealing with customer satisfaction. All of these entities are in this document referred to as the 0AM system (where the 0AM system also contains further entities).
  • management-based QoE m-based QoE
  • the 0AM system is typically interested in general QoE statistics from a certain area (which is configured as an area scope).
  • the m-based QoE configuration is sent directly from the 0AM system to the RAN nodes controlling cells that are within the area scope.
  • Each RAN node selects UEs that are within the area scope (and also fulfills any other relevant condition, such as supporting the concerned application/service type) and sends the m-based QoE configuration to these UEs.
  • the 0AM system With signaling-based QoE (s-based QoE), the 0AM system is interested in collecting QoE measurement results from a specific UE, e.g. because the user of the UE has filed a complaint.
  • the 0AM system sends the s-based QoE configuration to the HSS (in EPS/LTE) or UDM (in 5GS/NR), which forwards the QoE configuration to the UE’s current core network node (CN), e.g. an MME in EPS/LTE or an AMF in 5G/NR.
  • CN current core network node
  • 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.
  • 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 MCC+MNC+QMC ID, where the QMC ID is a string of 24 bits) will be associated with each QoE configuration.
  • the QoE reference is included in the container with measurement instructions and also sent to the RAN (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 also forwarded in an AT Command (which is the type of instructions used in the communication between the UE’s modem part and the UE’s application layer) together with the service type indication and the container with the measurement instructions.
  • 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 Reports with collected QoE measurement results (QoE reports) are sent from the UE application layer to the UE Access Stratum, which forwards them to the RAN, which forwards them to the MCE. These QoE measurement results are placed in a “container”, which is uninterpretable for the UE Access Stratum and the RAN. QoE reporting can be configured to be periodic or only sent at the end of an application session. Furthermore, the RAN can instruct the UE to pause QoE reporting, e.g. in case the cell/gNB is in a state of overload.
  • 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.
  • 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 explicit or may be implicit in the form of a QoE report sent when the application session and the associated QoE measurement session are concluded.
  • 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.
  • the area scope 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.
  • 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.
  • AT commands are used for communication between the AS (radio) layer and the application layer in the UE.
  • the AT commands are defined in 3GPP TS 27.007 version 17.3.0.
  • UTRAN can request the UE (using a UE Capability Enquiry RRC message) to report its capability, as shown in Figure 1.
  • Figure 1 illustrates UE capability enquiry procedure - UTRAN.
  • the UE can provide information about its capability using the UE Capability Information RRC message as shown in Figure 2.
  • Figure 2 illustrates transmission of UE capability information - UTRAN.
  • the UE can indicate support for QoE measurement and reporting in the UE Capability Information message.
  • the relevant indications are included in the “Measurement capability” IE, which in turn is included in the “UE radio access capability” IE, which is included in the UE Capability Information message.
  • the relevant definitions are copied from 3GPP TS 25.331 version 16.1.0 below.
  • the UTRAN can send a Measurement Control RRC message containing the “Application layer measurement configuration” IE.
  • Figure 3 illustrates measurement Control, normal case - UTRAN.
  • UTRAN - QoE measurement reporting - RRC signaling [0036] The UE can send QoE measurement results via UTRAN to the Collecting Entity using the “Measurement Report” RRC message including the “Application layer measurement reporting” IE.
  • Figure 4 illustrates Measurement report, normal case - UTRAN.
  • the UE may also perform Cell Update to indicate that an application layer measurement report is available in the UE.
  • SRB4 shall be used for the Measurement Report message carrying the "Application layer measurement reporting" IE.
  • the UE capability transfer is used to transfer UE radio access capability information from the UE to E-UTRAN.
  • Figure 5 illustrates UE capability transfer - E-UTRAN.
  • the UE-EUTRA-Capability IE is used to convey the E-UTRA UE Radio Access Capability Parameters and the Feature Group Indicators for mandatory features to the network.
  • the UE can include the “UE- EUTRA-Capability” IE.
  • the “UE-EUTRA-Capability “ IE may include the “UE-EUTRA- Capability-vl530-IEs” IE which can be used by the UE to indicate whether the UE supports QoE Measurement Collection for streaming services and/or MTSI services.
  • the relevant ASN. 1 code in the ASN.1 definition for UE-EUTRA-Capability IE is indicated below (where most of the ASN.1 code in the UE-EUTRA-Capability IE definition is omitted for clarity).
  • UE-EUTRA-Capabihty-vl530-IEs SEQUENCE ⁇ measParameters-v 1530 MeasParameters-v 1530
  • OPTIONAL OPTIONAL, fdd-Add-UE-EUTRA-Capabilities-v 1530 UE-EUTRA-CapabilityAddXDD-Mode- vl530 OPTIONAL, tdd-Add-UE-EUTRA-Capabilities-v!530 UE-EUTRA-CapabilityAddXDD-Mode- vl530 OPTIONAL, nonCriticalExtension UE-EUTRA-Capability-v 1540-IEs OPTIONAL
  • MeasParameters-vl530 SEQUENCE ⁇ qoe-MeasReport-r 15 ENUMERATED ⁇ supported ⁇ OPTIONAL, qoe-MTSI-MeasReport-rl5 ENUMERATED ⁇ supported ⁇ OPTIONAL, ca-IdleModeMeasurements-r 15 ENUMERATED ⁇ supported ⁇ OPTIONAL, ca-IdleModeValidityArea-rl5 ENUMERATED ⁇ supported ⁇
  • the RRCConnectionReconfiguration message is used to reconfigure the UE to setup or release the UE for Application Layer measurements. This is signaled in the measConfigAppLayer-rl5 IE within the OtherConfig IE.
  • the setup includes the transparent container measConfigAppLayerContainer IE which specifies the QoE measurement configuration for the application of interest and the serviceType IE which indicates the Application (or service) for which the QoE measurements are being configured. Supported services are streaming and MTSI.
  • measConfigAppLayerContainer i measConfigAppLayerContainer i
  • the field contains configuration of application layer measurements, see Annex L (normative) in
  • the UE shall: l>ifthe received OtherConfig includes the measConfigAppLayer.
  • the purpose of the “Application layer measurement reporting” procedure described in 3GPP TS 36.331 version 16.6.0 and shown below is to transfer the application layer measurement report to E-UTRAN, so that the E-UTRAN can forward the report to the O&M system, e.g. to a Measurement Collector Entity (MCE) or a Trace Collector Entity (TCE).
  • MCE Measurement Collector Entity
  • TCE Trace Collector Entity
  • FIG. 6 illustrates Application layer measurement reporting in E-UTRAN.
  • a UE capable of application layer measurement reporting in RRC CONNECTED state may initiate the procedure when configured with application layer measurement, i.e. when the measConfigAppLayer IE has been configured by E-UTRAN.
  • the UE uses the MeasReportAppLayer RRC message, which contains the measReportAppLayerContainer IE and the serviceType IE.
  • the UE upon initiating the application layer measurement reporting procedure, the UE shall:
  • MasReportAppLayer message is defined as follows in 3GPP TS 36.331 version 16.6.0:
  • MeasReportAppLayer-rl5 SEQUENCE ⁇ criticalExtensions CHOICE ⁇ measReportAppLayer-r 15 MeasReportAppLayer-r 15 -IES, criticalExtensionsFuture SEQUENCE ⁇
  • MeasReportAppLayer-rl5-IEs SEQUENCE ⁇ measReportAppLayerContainer-rl5 OCTET STRING (SIZE(1..8OOO)) OPTIONAL, serviceType-rl5 ENUMERATED ⁇ qoe, qoemtsi, spare6, spare5, spare4, spare3, spare2, spare 1 ⁇ OPTIONAL, nonCriticalExtension MeasReportAppLayer-v 1590-IEs
  • MeasReportAppLayer-v 1590-IEs :: SEQUENCE ⁇ lateNonCriticalExtension OCTET STRING OPTIONAL, nonCriticalExtension SEQUENCE ⁇ OPTIONAL
  • the configuration is signaled to the RAN (eNB) from the MME using the control plane protocol for the SI interface, i.e. S1AP, which is specified in 3GPP TS 36.413.
  • the “UE Application layer measurement configuration” IE defines configuration information for the QoE Measurement Collection (QMC) function. It is described in section 9.2.1.128 of 3GPP TS 36.413 version 16.7.0 as follows (note that this IE is included in the Trace Activation IE, which also, among other parameters, includes the Trace Collection Entity IP Address. IE):
  • the area scope parameter defines the area in terms of cells or Tracking Area/Routing Area/Location Area where the QMC shall take place. If the parameter is not present, the QMC shall be done throughout the PLMN specified in PLMN target.
  • the area scope parameter in UMTS is either:
  • LAI Location Area
  • the area scope parameter in LTE is either:
  • TAC Tracking Area
  • the area scope parameter will be either:
  • the parameter is mandatory if area based QMC is requested.
  • the UE In connected state, in the 3GPP specifications known as the RRC CONNECTED state, the UE has an active connection to the network for sending and receiving of data and signaling. In connected state, mobility is controlled by the network to ensure connectivity is retained to the UE with no interruption or noticeable degradation of the provided service as the UE moves between the cells within the network. To support network-controlled connected state mobility, as requested/configured by the network, the UE is required to search and perform measurements on neighbor cells both on the current carrier frequency (intrafrequency) and on other carrier frequencies (inter-frequency).
  • intrafrequency current carrier frequency
  • inter-frequency inter-frequency
  • the connected state mobility is network-controlled, and the UE does not take any autonomous decisions when to trigger a handover to a neighbor cell (except to some extent when the UE is configured for Conditional Handover, which is described in section 2.1.4.2). Instead, the UE sends the measurement results obtained for the serving and neighboring cells to the network where a decision is taken whether or not to perform a handover to one of the neighbor cells.
  • Two flavors of connected state mobility are described in this section: regular handover and conditional handover.
  • regular handover also referred to as just “handover” the UE is moved from a source node using a source cell connection, to a target node using a target cell connection where the target cell connection is associated with a target cell controlled by the target node.
  • the UE moves from the source cell to a target cell.
  • the source node and the target node may also be referred to as the source access node and the target access node or the source radio network node (i.e. the source RAN node) and the target radio network node (i.e. the target RAN node).
  • the source node and the target node are referred to as the source gNB and the target gNB.
  • the source node and the target node are different nodes, such as different gNBs. These cases are also referred to as inter-node or inter-gNB handover. In other cases, the source node and the target node are one and the same node, such as the same gNB. These cases are also referred to as intra-node or intra-gNB handover and covers the case when the source and target cells are controlled by the same node.
  • handover is performed within the same cell and thus also within the same node controlling that cell. These cases are referred to as intra-cell handover.
  • the source node (or source access node) and the target node (target access node) refer to a role served by a given access node during a handover of a specific UE.
  • a given access node may serve as source access node during handover of one UE, while it also serves as the target access node during handover of a different UE.
  • the same access node serves both as the source access node and target access node for that UE.
  • An inter-node handover can further be classified as an Xn-based or NG-based handover depending on whether the source and target node communicate directly using the Xn interface or indirectly via the Core Network using the NG interface.
  • Figure 7 illustrates a simplified signaling flow between the UE, the source gNB and the target gNB during an Xn-based inter-node handover in NR.
  • control plane data i.e. RRC messages such as the measurement report (MeasurementReport), Handover Command and Handover Complete messages
  • SRBs Signaling Radio Bearers
  • DRBs Data Radio Bearers
  • operations 301-302 correspond to the UE has an active connection to the source gNB where user data is sent and received to/from the network. Due to some trigger in the source gNB, e.g. a measurement report received from the UE, the source gNB decides to handover the UE to a target (neighbor) cell controlled by the target gNB.
  • Operation 303 corresponds to the source gNB sends the XnAP HANDOVER REQUEST message to the target gNB passing a transparent RRC container with necessary information to prepare the handover at the target side. The information includes for example the target cell id, the target security key, the current source configuration and UE capabilities.
  • Operation 304 corresponds to the target gNB prepares the handover and responds with the XnAP HANDOVER REQUEST ACKNOWLEDGE message to the source gNB, which includes the Handover Command (a RRCReconfiguration message containing the reconfigurationWithSync field) to be sent to the UE.
  • the Handover Command includes configuration information that the UE should apply once it connects to the target cell, e.g., random access configuration, a new C-RNTI assigned by the target node, security parameters, etc.
  • Operation 305 corresponds to the source gNB triggers the handover by sending the Handover Command (received from the target gNB in the previous step) to the UE.
  • Operation 306 corresponds to upon reception of the Handover Command the UE releases the connection to the old (source) cell, starts the handover supervision timer T304, and starts to synchronize to the new (target) cell.
  • Operations 307-309 correspond to the source gNB stops scheduling any further DL user data to the UE and sends the XnAP SN STATUS TRANSFER message to the target gNB indicating the latest PDCP SN transmitter and receiver status.
  • the source gNB now also starts to forward DL user data received from the Core Network to the target gNB, which buffers this data for now.
  • Operation 310 corresponds to once the UE the has completed the random access procedure in the target cell, the UE stops the T304 timer and sends the Handover Complete message to the target gNB.
  • Operation 311 corresponds to upon receiving the Handover Complete message, the target gNB starts sending (and receiving) user datato/from the UE.
  • the target gNB requests the Core Network (CN) to switch the DL user data path between the User Plane Function (UPF) and the source node to the target node (communication to the CN is not shown in the Figure).
  • the target gNB sends the XnAP UE CONTEXT RELEASE message to the source gNB to release all resources associated to the UE.
  • CHO Conditional Handover
  • CHO enables the network to transmit the Handover Command to the UE at an early stage when the quality of the radio link is still good, i.e. before the UE is getting close to the cell edge.
  • the network configures the UE with one or more candidate target cells and with a CHO specific execution condition for each target cell.
  • the CHO execution conditions are then evaluated by the UE and when fulfilled for one of the candidate target cells, the UE triggers a handover to that target cell.
  • Figure 8 illustrates inter-gNB Conditional Handover in NR.
  • the RRCReconfiguration message in step 6 is the Handover Command containing the CHO configuration(s).
  • the source node Based on e.g. a Measurement Report received from the UE, the source node decides to configure the UE for CHO (step 2 in Figure 3).
  • the source node prepares one or potentially more candidate target nodes by including a CHO indicator and the current UE configuration in the HANDOVER REQUEST message sent over Xn (step 3).
  • CHO enables the network to prepare the UE with more than one candidate target cell, each candidate target cell with its own target cell configuration (RRC Reconfiguration) and its own CHO execution condition.
  • the target cell configuration is generated by the candidate target node while the CHO execution condition is configured by the source node.
  • the CHO execution condition may consist of one or two trigger conditions - the A3 and A5 signal strength/quality based events as defined in 3GPP TS 38.331 [5], [0096]
  • the Handover Command (RRCReconfiguration message) sent to the UE in step 6 is generated by the candidate target node but transmitted to the UE in the source cell by the source node.
  • the Handover Command is sent from the candidate target node to the source node within the Xn HANDOVER REQUEST ACKNOWLEDGE message (step 5) as a transparent container, meaning that the source node does not change the content of the Handover Command.
  • the target cell configuration (RRC Reconfiguration for the UE to use in the candidate target cell) and the CHO execution condition for each candidate target cell provided by the network to the UE is also known as the CHO configuration.
  • the target cell configuration When received by the UE in the Handover Command (RRCReconfiguration message in step 6), the target cell configuration is not applied immediately as in a regular (non-CHO) handover. Instead, the UE starts to evaluate the CHO execution condition(s) configured by the network.
  • the network may configure the UE with one or two trigger conditions (A3 and/or A5 event) per CHO execution condition and candidate target cell. If the UE is configured with two trigger conditions, then both events need to be fulfilled in order to trigger the CHO to the candidate target cell.
  • the UE detaches from the source cell, applies the associated target cell configuration (RRC Reconfiguration) and starts the handover supervision timer T304.
  • the UE now connects to the target node as in a regular handover (step 8). Any CHO configuration stored in the UE after completion of the RRC handover procedure is now released.
  • the target node sends the HANDOVER SUCCESS message over Xn to the source node to inform that the UE has successfully accessed the target cell (step 8a).
  • Triggering of data forwarding to the target node is typically done after receiving the HANDOVER SUCCESS message in the source node - this is also known as “late data forwarding”.
  • data forwarding may be triggered at an earlier stage in the handover procedure, after receiving the RRCReconfigurationComplete message from the UE (step 7). This mechanism is also known as “early data forwarding”.
  • the source node needs to cancel the CHO for the candidate target cells not selected by the UE.
  • the source node sends the HANDOVER CANCEL message over Xn towards the other signalling connection(s) or other candidate target node(s) to cancel the CHO and thus to initiate a release of the reserved resources in the target node(s) (step 8c).
  • the handover attempt fails due to e.g. a radio link failure or expiry of timer T304
  • the UE will typically perform a cell selection and continue with a re-establishment procedure. But when a CHO execution attempt fails and the selected cell is associated to a candidate target cell included in the CHO configuration, the UE will instead attempt a CHO execution to the selected target cell. This UE behaviour is however enabled/disabled by means of network configuration.
  • Some embodiments of the present disclosure are directed to a method performed by a source node of a radio communications system for CHO for a UE.
  • the method includes sending a current session status, indicating whether the current session is ongoing or not, to a target node based on successful CHO execution to the target node.
  • the sending of the current session status is performed instead of updating handover preparation information for a CHO configuration in the target node each time the UE’s current session status changes for a Quality of Experience (QoE) configuration in the UE.
  • the current session status may be sent to the target node in a SN STATUS TRANSFER XnAP message, and the sending may be triggered by a HANDOVER SUCCESS XnAP message received from the target node at the source node which indicates successful completion of the CHO execution.
  • the current session status may be sent to the target node in an EARLY STATUS TRANSFER XnAP message prior to receiving a HANDOVER SUCCESS XnAP message from the target node at the source node which indicates successful completion of the CHO execution.
  • Some other related embodiments of the present disclosure are directed to a source node of a radio communications system for CHO for a UE.
  • the source node includes processing circuitry operative to send a sending a current session status, indicating whether the current session is ongoing or not, to a target node based on successful CHO execution to the target node.
  • the source node further includes power supply circuitry configured to supply power to the processing circuitry.
  • Potential advantages that may be provided by one or more of these embodiments and further embodiments disclosed herein include that potentially extensive and unnecessary (in case of multiple QoE measurement status changes during CHO execution) inter-gNB and gNB-UE signaling of configuration updates can be avoided. Avoiding such signalling can reduce the power consumption of UEs and source nodes, and improve how efficiently they use available RF communication resources.
  • Figure 1 illustrates UE capability enquiry procedure - UTRAN
  • Figure 2 illustrates transmission of UE capability information - UTRAN
  • Figure 3 illustrates measurement Control, normal case - UTRAN
  • Figure 4 illustrates Measurement report, normal case - UTRAN
  • Figure 5 illustrates UE capability transfer - E-UTRAN
  • Figure 6 illustrates Application layer measurement reporting in E-UTRAN
  • Figure 7 illustrates a simplified signaling flow between the UE, the source gNB and the target gNB during an Xn-based inter-node handover in NR;
  • FIG 8 illustrates inter-gNB Conditional Handover in NR.
  • the RRCReconfiguration message in step 6 is the Handover Command containing the CHO configuration(s);
  • Figure 9 illustrates a flowchart of operations which may be performed by a source node in accordance with some embodiments.
  • Figure 10 is a block diagram of a communication system in accordance with some embodiments;
  • FIG. 11 is a block diagram of a user equipment in accordance with some embodiments
  • Figure 12 is a block diagram of a network node in accordance with some embodiments.
  • Figure 13 is a block diagram of a host computer communicating with a user equipment in accordance with some embodiments.
  • Figure 14 is a block diagram of a virtualization environment in accordance with some embodiments.
  • Figure 15 is a block diagram of a host computer communicating via a base station with a user equipment over a partially wireless connection in accordance with some embodiments in accordance with some embodiments.
  • the candidate target node(s) (e.g. candidate target gNB(s)) is (are) prepared with the configuration the UE has in the source node (e.g. source gNB) and the source cell, and the UE is prepared through an RRCReconfiguration message (in NR) containing the configuration(s) to apply when/if the UE eventually connects to the candidate target node, or one of the candidate target nodes.
  • RRCReconfiguration message in NR
  • the UE configuration information sent from the source node to the candidate target node(s) may include information (per QoE configuration) of whether a session (i.e. an application session with an associated QoE measurement session) is ongoing in the UE. This is rational during regular handover, because the target node may use this information as input to a possible decision to release the QoE configuration in the UE (e.g. if the UE has exited the area scope associated with the QoE configuration) or for decisions and actions related to alignment of MDT measurements and QoE measurements.
  • each update also results in a need to change the configuration (for each candidate target cell controlled by the candidate target node) that the candidate target node has prepared for the UE (and which has been transferred to the UE via the source node) to be applied if the UE eventually connects to the candidate target node.
  • each update of the CHO configuration in a candidate target cell means that the CHO configuration is replaced and a new HandoverCommand has to be provided by the candidate target node.
  • various embodiments are directed to providing operations for a source node of a conditional handover for a UE, which instead of updating the handover preparation information for a CHO configuration in a candidate target node every time the concerned UE’s session ongoing/not ongoing status changes for a QoE configuration in the UE, sends a valid session ongoing/not ongoing status (per QoE configuration in the UE) to the target node upon successful CHO execution to the target node.
  • the per QoE configuration session ongoing/not ongoing status may be sent to the target node in the SN STATUS TRANSFER XnAP message, which is triggered by the HANDOVER SUCCESS XnAP message sent from the target node to the source node to indicate successful completion of the CHO execution.
  • Signaling, from the source node to a candidate target node, of an intention to send the UE’s session ongoing/not ongoing status (per QoE configuration in the UE) upon successful execution of the CHO (referred to as the “feature” in the remainder of this sentence), and/or signaling, from a candidate target node to the source node, of support or lack of support for the feature, or of a request to the source node to use the feature, are also parts of some embodiments of the solution.
  • the source node (e.g. a gNB) of a conditional handover for a UE instead of updating the handover preparation information for a CHO configuration in a candidate target node (e.g. a gNB) every time the concerned UE’s session ongoing/not ongoing status changes for a QoE configuration in the UE, sends, at that point in time, valid session ongoing/not ongoing status (per QoE configuration in the UE) to the target node upon successful CHO execution to the target node.
  • a candidate target node e.g. a gNB
  • the per QoE configuration session ongoing/not ongoing status may be sent to the target node in the SN STATUS TRANSFER XnAP message, which is triggered by the HANDOVER SUCCESS XnAP message sent from the target node to the source node to indicate successful completion of the CHO execution.
  • a potential advantage of these embodiments is that potentially extensive and unnecessary (in case of multiple QoE measurement status changes during CHO execution) inter-gNB and gNB-UE signaling of configuration updates can be avoided.
  • UE terminal equipment
  • wireless terminal wireless terminal
  • the terms “source node”, “target node” and “candidate target node” are often used in the solution description.
  • the “node” in these terms should be understood as typically being a RAN node in NR, LTE or UMTS, e.g. an RNC or a Node B in UMTS, an eNB (or an ng-eNB or a part of an eNB in case the eNB is split into multiple entities/nodes in a split eNB architecture) in LTE or a gNB in NR, or an en-gNB or a part of a gNB in NR (when the split gNB architecture is applied, dividing the gNB into multiple separate entities or nodes).
  • the different entities/nodes belonging to a gNB in a split gNB architecture constitute a range of different nodes/entities, e.g.: gNB-CU (often referred to as just CU), gNB-DU (often referred to as just DU), gNB-CU-CP and gNB- CU-UP.
  • the eNB may also be subject to a split architecture, in which case it may be split into an eNB-CU and one or more eNB-DUs, and wherein the eNB-CU may be further divided into an eNB-CU-CP and an eNB-CU-UP.
  • the “node” in the terms may also refer to an lAB-donor, lAB-donor-CU, lAB-donor-DU, lAB-donor-CU-CP, or an lAB-donor-CU-UP.
  • modem modem
  • radio layer RRC layer
  • radio network layer radio network layer
  • access stratum and “radio layer” are used interchangeably when referring to a UE.
  • service subtype and “subservice type” are used interchangeably.
  • the term “session” is used frequently herein, and it may refer to either a QoE measurement session or an application session or an application session for which QoE measurement is applied.
  • conditional PSCell change or conditional PSCell addition or conditional SCell addition.
  • the UE’s “source cell configuration” refers to the configuration the UE applies in the source cell.
  • the UE’s “target cell configuration” or “candidate target cell configuration” refers to the configuration the UE applies in the target cell or candidate target cell.
  • the solution is primarily described in 5G/NR terms, implying application of the solution in 5G/NR, but the solution is also applicable in LTE (in which case for instance a gNB would be replaced by an eNB, and an RRCReconfiguration message would be replaced by an RRCConnectionReconfiguration message) or UMTS.
  • a cell which the UE potentially can connect to i.e., if the CHO execution condition is fulfilled for the cell
  • candidate target cell a cell which the UE potentially can connect to
  • candidate target node a RAN node controlling a candidate target cell
  • this terminology becomes a bit blurred.
  • the concerned cell may be referred to as either a “candidate target cell” or a “target cell”.
  • a RAN node controlling such a cell may in this situation be referred to as either a “candidate target node” or a “target node”.
  • the source node does not update the CHO configuration in candidate target nodes when the session ongoing/not ongoing status changes while the CHO is configured (i.e. between the provision of the CHO configuration and the possible CHO execution). Instead, source node sends the current session ongoing/not ongoing status (per QoE configuration in the UE) to the target node upon successful execution of the CHO.
  • Figure 9 illustrates a flowchart of operations which may be performed by a source node in accordance with some embodiments.
  • the operations send 900 a current session ongoing status or not ongoing status to a target node based on successful CHO execution to the target node.
  • the phrase "current session ongoing status or not ongoing status” is also interchangeable described herein as a "current session status, indicating whether the current session is ongoing or not.”
  • the target node may be a “candidate target node.”
  • the sending 900 of the current session ongoing status or not ongoing status may be performed instead of updating handover preparation information for a CHO configuration in the target node each time the UE’s session ongoing status or not ongoing status changes for a Quality of Experience, QoE, configuration in the UE.
  • the sending of the current session ongoing status or not ongoing status may be pursuant to a Quality of Experience, QoE, configuration in the UE.
  • the current session ongoing status or not ongoing status may be sent to the target node in a SN STATUS TRANSFER XnAP message, where the sending is triggered by a HANDOVER SUCCESS XnAP message received from the target node at the source node which indicates successful completion of the CHO execution.
  • the current session ongoing status or not ongoing status is sent to the target node in an EARLY STATUS TRANSFER XnAP message prior to receiving a HANDOVER SUCCESS XnAP message from the target node at the source node which indicates successful completion of the CHO execution.
  • the source node when a conditional handover is successfully executed, the source node is informed of the execution in the XnAP message HANDOVER SUCCESS sent from the target node to the source node.
  • the source node may then inform the target node of whether there is any ongoing session in the UE (per QoE configuration in the UE).
  • the target node may, e.g. be informed in the existing SN STATUS TRANSFER XnAP message or in a new XnAP message.
  • the source node updates the candidate target node with the current/latest session ongoing/not ongoing status (per QoE configuration in the UE) using an EARLY STATUS TRANSFER XnAP message prior to receiving a HANDOVER SUCCESS XnAP message.
  • Using the EARLY STATUS TRANSFER XnAP message may be seen as a compromise between the baseline, which is to update (replace) the CHO configuration in the candidate target node every time the session ongoing/not ongoing status changes for a QoE configuration in the UE, and the solution using the SN STATUS TRANSFER XnAP message which is sent after the CHO execution.
  • the EARLY STATUS TRANSFER XnAP message is sent before the source node knows which candidate target node the UE will select (if any), but contrary to the baseline solution, it does not require update of the CHO configuration in the candidate target node and no replacement of the HandoverCommand .
  • the source node sends the EARLY STATUS TRANSFER XnAP message to a selected subset of the configured candidate target nodes, which may be selected based on various inputs or measurements collected from the network and/or the UE, e.g., UE trajectory (based on which the source node can conclude the relevant subset of candidate target nodes).
  • Operations of these embodiments may also be applied in cases where the CHO related signaling takes place via the core network over NG interfaces (and a possibly inter- AMF interface), using NGAP signaling (including use of transparent containers to transfer information from the source node to the candidate target node(s), and from the candidate target node(s) (or the target node) to the source node (where the information in such transparent containers is not interpreted by the core network node(s)), where examples of such transparent containers used in NGAP signaling include the Source to Target Transparent Container IE and the Target to Source Transparent Container IE.
  • New NGAP message(s) or extended use of existing NGAP messages) for the CHO related signaling or, in particular, for conveying the information introduced herein to support the proposed solution, may also be used.
  • the HANDOVER NOTIFY NGAP message from the target node to the AMF (informing the AMF of the completion of the CHO) and the (thereby triggered) HANDOVER SUCCESS NGAP message from the AMF to the source node, may both be extended to carry information related to the proposed solution between the involved RAN nodes.
  • the UPLINK RAN STATUS TRANSFERNGAP message from the source node to the AMF and the DOWNLINK RAN STATUS TRANSFER NGAP message from the AMF to the target node (or candidate target node) may both be extended to carry information related to the proposed solution between the involved RAN nodes. For example, these messages may be extended to carry information about the session ongoing/not ongoing status per QoE configuration in a UE.
  • NGAP signaling e.g. using the above exemplified messages (possibly with extensions) may be used for any of the information exchange/signaling described herein for various embodiments.
  • these operations can be applied to a conditional handover that requires only radio access technology (RAT) change, without core network change, i.e., the inter-RAT handover, e.g., between LTE and NR (e.g., for a service type supported in both LTE and NR).
  • RAT radio access technology
  • the sending 900 of Figure 9 can be used with a CHO execution to the target node which is a conditional handover that requires only RAT change without core network change.
  • the solution can be applied to a conditional handover that involves core network change, i.e., inter-system conditional handover, e.g., a conditional handover via the core network between the LTE core network (EPC) and NR core network (5GC), which may involve NGAP signaling (between NG-RAN and AMF), the signaling between AMF and MME and S1AP signaling (between the EPC and LTE RAN).
  • EPC LTE core network
  • NR core network 5GC
  • the sending 900 of Figure 9 can be used with a CHO execution to the target node which is a conditional handover that requires RAT change with core network change.
  • the source node may not send any information at all to the candidate target node(s) regarding the session ongoing/not ongoing status for the QoE configuration(s) configured in the UE which is subject to the CHO configuration.
  • the source node may send to the candidate target node(s) an indication of the current session ongoing/not ongoing status for each QoE configuration in the UE.
  • the source node may subsequently (upon successful execution of the CHO) send to the target node (i.e.
  • the candidate target node towards which the UE has executed the CHO an indication of the session ongoing/not ongoing status for a QoE configuration in the UE only if this status has changed for the QoE configuration since the time of configuration of the CHO (i.e. if the latest known session ongoing/not ongoing status for the QoE configuration - i.e. the status that was valid prior to the CHO execution - is different from the session ongoing/not ongoing status indicated to the candidate target node during the CHO preparation phase).
  • the source node sent the session ongoing/not ongoing status for a QoE configuration in the UE to the candidate target node during the CHO preparation phase and this status has changed when the CHO is executed (e.g.
  • the source node may indicate to the candidate target node (e.g. in the SN STATUS TRANSFER XnAP message or a new XnAP message) that the session ongoing/not ongoing status for the QoE configuration has changed by including an indication in the message indicating that the status has changed, e.g. in the form of a flag or a single bit parameter, or in the form of a Boolean parameter (which e.g. may be set to “true” if the status has changed and set to “false” if the status has not changed).
  • the candidate target node e.g. in the SN STATUS TRANSFER XnAP message or a new XnAP message
  • an alternative trigger for the source node to send the UE’s session ongoing/not ongoing status (per QoE configuration in the UE) to the target node is reception of an end marker in the downlink user plane path from a UPF in the core network.
  • the source node may be triggered to send the UE’s session ongoing/not ongoing status (per QoE configuration in the UE) by reception of a HANDOVER SUCCESS NGAP message or a UE CONTEXT RELEASE COMMAND NGAP message.
  • the source node sends the UE’s session ongoing/not ongoing status (per QoE configuration in the UE) in an UPLINK RAN STATUS TRANSFER NGAP message during as a part of a CHO signaled over the NG interface.
  • Another option is to use a new NGAP message.
  • a candidate target node may indicate in the HANDOVER REQUEST ACKNOWLEDGE XnAP message to the source node whether it wants the source node to report the UE’s session ongoing/not ongoing status upon verification of CHO execution, i.e. upon reception of the HANDOVER SUCCESS XnAP message. That is, as one option, a candidate target node may indicate in the HANDOVER REQUEST ACKNOWLEDGE XnAP message to the source node that it wants the source node to report the UE’s session ongoing/not ongoing status upon verification of CHO execution, i.e. upon reception of the HANDOVER SUCCESS XnAP message.
  • a candidate target node may indicate in the HANDOVER REQUEST ACKNOWLEDGE XnAP message to the source node that it does not want the source node to report UE’s session ongoing/not ongoing status upon verification of CHO execution. This may be useful if the candidate target node does not use any method that requires knowledge of the session ongoing/not ongoing status of the QoE configuration(s) in the UE.
  • the candidate target node may use a message related to the CHO completion phase., e.g. the HANDOVER SUCCESS XnAP message.
  • a candidate target node may indicate in the HANDOVER SUCCESS XnAP message that it wants the source node to report the UE’s session ongoing/not ongoing status (e.g. in a SN STATUS TRANSFER XnAP message or a new message).
  • a candidate target node may indicate in the HANDOVER SUCCESS XnAP message that it does not want the source node to report the UE’s session ongoing/not ongoing status.
  • the source node may ask a candidate target node if it wants to receive QoE measurement session status information, e.g. in the SN STATUS TRANSFER message. If the answer is “no”, this may be qualified by “not supporting the feature where this status information is sent in the SN STATUS TRANSFER message” or “no support of the QoE framework in general”. In the former case, the source node may refrain from providing the QoE measurement session status information in the SN STATUS TRANSFER message, but instead keep updating the candidate target node (e.g. providing a new or updated CHO configuration) whenever the session ongoing/not ongoing status changes for a QoE configuration in the UE. In the latter case, i.e.
  • the source node may provide a new CHO configuration to the candidate target node (e.g. in a new HANDOVER REQUEST XnAP message), this time without any information related to QoE and the source node will also refrain from sending any QoE measurement session status information in the SN STATUS TRANSFER message to the candidate target node (and the source node may also release the QoE configuration(s) in the UE, or pause the QoE reporting for all QoE configuration(s) in the UE).
  • the sending of session start/stop indication from the source node to the candidate target node selected for CHO can be regulated by indications sent from the selected candidate target node to the source node. This can potentially further reduce the signaling burden between RAN nodes, or enable the target node to reconstruct the history of sessions for the UE, that can be used, among other things, for alignment purpose between QoE (and/or RAN Visible QoE) and MDT.
  • the candidate target node used for CHO execution sends to the source node, as part of CHO completion phase (e.g. as part of an XnAP HANDOVER SUCCESS message), one or more or a combination of the following indications:
  • QoE reporting and/or RAN Visible QoE reporting is paused at the target node (for all service types and/or service subtypes, or selectively per service types or service subtypes, or for the specific UE).
  • target node has received a session stop or a session end indication from the UE (and that the target node is willing to, or wishes to, receive the corresponding session start indication, i.e. the target node may explicitly or implicitly (e.g. implicit in the indication of reception of a session stop/end indication) request the source node to send the corresponding start indication).
  • the target node may explicitly or implicitly (e.g. implicit in the indication of reception of a session stop/end indication) request the source node to send the corresponding start indication).
  • Indications of services types (or subservice types or service subtypes) that can continue for the UE at target node e.g. as an implicit indication that only session start/stop/end indications related to services that have continued at the target node are relevant).
  • the source node can determine which information (if any) to send to the candidate target node used for CHO execution, pertaining to session start/stop/end indication(s), or the session ongoing/not ongoing status (per QoE configuration in the UE) for the UE subject to CHO.
  • Reception of none of the indications listed above may trigger the source not to always send the session ongoing/not ongoing status to the target node.
  • reception of no indication may trigger the source not to not send the session ongoing/not ongoing status to the target node.
  • Target Node embodiments upon CHO execution failure is now described with regard to some embodiments.
  • the CHO execution may lead to the CHO execution failure (e.g., CHO to wrong cell). If the CHO execution fails (e.g. due to expiration of supervision timer T304), the UE initiates the connection re-establishment procedure by selection a cell for the reestablishment. This cell may happen to be a CHO candidate target cell or it may happen to be a cell which is not a CHO candidate target cell. If the selected cell is a CHO candidate target cell, the UE executes the CHO towards the RAN node controlling the selected cell (instead of proceeding with the regular re-establishment procedure).
  • the CHO execution failure e.g., CHO to wrong cell.
  • the UE proceeds with the regular re-establishment procedure.
  • Another failure variant is that the UE successfully executes the CHO towards a target node and then the UE experiences a radio link failure (RLF) at the target cell right after the successful execution of the CHO.
  • the UE then initiates the connection re-establishment procedure (and since the CHO has been successfully completed, the option of “converting” the re-establishment procedure to a CHO is no longer available).
  • RLF radio link failure
  • the UE selects a CHO candidate target cell upon failure of the CHO execution
  • the UE fails to execute the CHO (e.g. due to expiration of supervision timer T304) and initiates connection re-establishment by selecting a cell and this cell (in this case) happens to be another (second) CHO candidate target cell (i.e. for which the UE has a CHO configuration) which may belong to another (second) RAN node. Since the selected cell is a CHO candidate target cell, the UE executes the CHO towards the second RAN node. Assuming that this CHO execution succeeds, the second RAN node sends a HANDOVER SUCCESS XnAP message to the source node and the rest of the procedure follows what has been described above for the main embodiments. The UE selects a non-CHO candidate target cell after failure of the CHO execution
  • the UE after failing a triggered CHO execution (e.g. due to expiration of supervision timer T304), the UE initiates the connection re-establishment procedure by selecting a cell, which may belong to a second RAN node.
  • the selected cell is not a CHO candidate target cell, which means that the UE proceeds with the regular re-establishment procedure.
  • the second RAN node fetches the UE context from the source RAN node using the RETRIEVE UE CONTEXT REQUEST XnAP message (which the source RAN node will respond to with the RETRIEVE UE CONTEXT RESPONSE XnAP message).
  • the second RAN node also retrieves the latest session ongoing/not ongoing status of each QoE configuration in the UE.
  • this session status information is made part of the UE context and then no further action than the regular context fetch procedure (i.e. sending the RETRIEVE UE CONTEXT REQUEST XnAP message) is needed from the second RAN node to retrieve the session status information.
  • the second RAN node explicitly indicates, e.g. using a new indication in the RETRIEVE UE CONTEXT REQUEST XnAP message, that it wants the source RAN node to transfer the UE’s latest session ongoing/not ongoing status per QoE configuration in the UE, e.g.
  • the source RAN shall then send the fmal/latest update of the QoE measurement session status to the second RAN node.
  • the UE selects a non-CHO candidate target cell after experiencing RLF after a successful CHO execution
  • the UE upon experiencing RLF after successful CHO execution (in a cell belonging to a RAN node denoted as the first RAN node), the UE initiates the connection re-establishment procedure.
  • This procedure begins with a cell selection, after which the UE sends an RRCReestablishmentRequest message to the RAN node controlling the selected cell (where this RAN node is denoted as the second RAN node).
  • the second RAN node fetches the UE context from the UE’s latest serving RAN node, which in this example was the first RAN node (to which the UE performed the successful CHO execution), by sending a RETRIEVE UE CONTEXT REQUEST XnAP message (which the source RAN node will respond to with the RETRIEVE UE CONTEXT RESPONSE XnAP message).
  • the second RAN node also retrieves the latest session ongoing/not ongoing status of each QoE configuration in the UE, as described above.
  • the QoE measurement session status information is made part of the UE context and then no further action than the regular context fetch procedure (i.e. sending the RETRIEVE UE CONTEXT REQUEST XnAP message) is needed from the second RAN node to retrieve the session status information.
  • the second RAN node explicitly indicates, e.g. using a new indication in the RETRIEVE UE CONTEXT REQUEST XnAP message, that it wants the first RAN node to transfer the UE’s latest session ongoing/not ongoing status per QoE configuration in the UE, e.g. in the RETRIEVE UE CONTEXT RESPONSE XnAP message, and then the first RAN node returns the requested QoE measurement session status information.
  • a feature that is about to be standardized for QoE for NR is the possibility for the network to send an instruction to the UE to pause (or resume) sending of QoE reports. This can be indicated per QoE configuration in the UE and possibly there will also be a possibility to indicate that QoE reporting is paused/resumed for all QoE configurations in the UE.
  • This pause QoE reporting feature is primarily intended to be used when the network experiences an overload condition (in the radio interface or in the processing capacity or some other resource) and makes the UE stop sending QoE reports, as instructed, until a corresponding instruction to resume the QoE reporting is sent from the network to the UE.
  • the above described solution targeting a UE’s session ongoing/not ongoing status can in all relevant aspects be generalized to, or extended to, handling of changes of the paused/not paused QoE reporting status per QoE configuration in a UE (instead of changes in the session ongoing/not ongoing status per QoE configuration in a UE) while the UE is configured for CHO (i.e. during the time between the provision of the CHO configuration and the possible execution of the CHO).
  • the serving/source node may avoid updating the UE context previously sent to candidate target node(s) when/if the UE’s status changes with regards to QoE reporting being paused or not paused (per QoE configuration in the UE). Instead, the source node indicates the current paused/not paused QoE reporting status (per QoE configuration in the UE) to the target node upon successful execution of the CHO, where such indication(s) may be sent e.g. in a SN STATUS TRANSFER XnAP message from the source node to the target node, triggered by a HANDOVER SUCCESS message sent from the target node to the source node.
  • modules may be stored in memory 2210 of Figure 11, and these modules may provide instructions so that when the instructions of a module are executed by respective communication device processing circuitry 2202, processing circuitry 2202 performs respective operations disclosed herein.
  • modules may be stored in memory 3304 of Figure 12, and these modules may provide instructions so that when the instructions of a module are executed by respective RAN node processing circuitry 2220, RAN node 3000 performs respective operations of the flow chart.
  • the operations send 900 a current session ongoing status or not ongoing status to a target node based on successful CHO execution to the target node.
  • the target node may be a "candidate target node.”
  • the sending 900 of the current session ongoing status or not ongoing status may be performed instead of updating handover preparation information for a CHO configuration in the target node each time the UE’s session ongoing status or not ongoing status changes for a Quality of Experience, QoE, configuration in the UE.
  • the sending of the current session ongoing status or not ongoing status may be pursuant to a Quality of Experience, QoE, configuration in the UE.
  • the current session ongoing status or not ongoing status may be sent to the target node in a SN STATUS TRANSFER XnAP message, where the sending is triggered by a HANDOVER SUCCESS XnAP message received from the target node at the source node which indicates successful completion of the CHO execution.
  • the current session ongoing status or not ongoing status is sent to the target node in an EARLY STATUS TRANSFER XnAP message prior to receiving a HANDOVER SUCCESS XnAP message from the target node at the source node which indicates successful completion of the CHO execution.
  • modules may be stored in memory 3304 of Figure 12, and these modules may provide instructions so that when the instructions of a module are executed by respective CN node processing circuitry 3302, CN node 3000 performs respective operations of the flow chart.
  • the operations send 900 a current session ongoing status or not ongoing status to a target node based on successful CHO execution to the target node.
  • the target node may be a "candidate target node.”
  • the sending 900 of the current session ongoing status or not ongoing status may be performed instead of updating handover preparation information for a CHO configuration in the target node each time the UE’s session ongoing status or not ongoing status changes for a Quality of Experience, QoE, configuration in the UE.
  • the sending of the current session ongoing status or not ongoing status may be pursuant to a Quality of Experience, QoE, configuration in the UE.
  • the current session ongoing status or not ongoing status may be sent to the target node in a SN STATUS TRANSFER XnAP message, where the sending is triggered by a HANDOVER SUCCESS XnAP message received from the target node at the source node which indicates successful completion of the CHO execution.
  • the current session ongoing status or not ongoing status is sent to the target node in an EARLY STATUS TRANSFER XnAP message prior to receiving a HANDOVER SUCCESS XnAP message from the target node at the source node which indicates successful completion of the CHO execution.
  • Figure 10 shows an example of a communication system 1000 in accordance with some embodiments.
  • the communication system 1000 includes a telecommunication network 1102 that includes an access network 1104, such as a radio access network (RAN), and a core network 1106, which includes one or more core network nodes 1108.
  • the access network 1104 includes one or more access network nodes, such as network nodes 1110A and 1110B (one or more of which may be generally referred to as network nodes QQ110), or any other similar 3 rd Generation Partnership Project (3GPP) access node or non-3GPP access point.
  • 3GPP 3 rd Generation Partnership Project
  • the network nodes QQ110 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 1112A, 1112B, 1112C, and 1112D (one or more of which may be generally referred to as UEs QQ112) to the core network 1106 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 1000 may include any number of wired or wireless networks, network nodes, UEs, and/or any other components or systems that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections.
  • the communication system 1000 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system.
  • the UEs QQ112 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 QQ110 and other communication devices.
  • the network nodes QQ110 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs QQ 112 and/or with other network nodes or equipment in the telecommunication network 1102 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 1102.
  • the core network 1106 connects the network nodes QQ110 to one or more hosts, such as host 1016. 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 1106 includes one more core network nodes (e.g., core network node 1108) 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 1108.
  • 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 1016 may be under the ownership or control of a service provider other than an operator or provider of the access network 1104 and/or the telecommunication network 1102, and may be operated by the service provider or on behalf of the service provider.
  • the host 1016 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio/video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.
  • the communication system 1000 of Figure 10 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 1102 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 1102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 1102. For example, the telecommunications network 1102 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)ZMassive loT services to yet further UEs.
  • URLLC Ultra Reliable Low Latency Communication
  • eMBB Enhanced Mobile Broadband
  • mMTC Massive Machine Type Communication
  • the UEs QQ112 are configured to transmit and/or receive information without direct human interaction.
  • a UE may be designed to transmit information to the access network 1104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1104.
  • 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 1114 communicates with the access network 1104 to facilitate indirect communication between one or more UEs (e.g., UE 1112C and/or 1112D) and network nodes (e.g., network node 1110B).
  • the hub 1114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs.
  • the hub 1114 may be a broadband router enabling access to the core network 1106 for the UEs.
  • the hub 1114 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 QQ110, or by executable code, script, process, or other instructions in the hub 1114.
  • the hub 1114 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 1114 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 1114 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 1114 then provides to the UE either directly, after performing local processing, and/or after adding additional local content.
  • the hub 1114 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.
  • the hub 1114 may have a constant/persistent or intermittent connection to the network node 1110B.
  • the hub 1114 may also allow for a different communication scheme and/or schedule between the hub 1114 and UEs (e.g., UE 1112C and/or 1112D), and between the hub 1114 and the core network 1106.
  • the hub 1114 is connected to the core network 1106 and/or one or more UEs via a wired connection.
  • the hub 1114 may be configured to connect to an M2M service provider over the access network 1104 and/or to another UE over a direct connection.
  • UEs may establish a wireless connection with the network nodes QQ110 while still connected via the hub 1114 via a wired or wireless connection.
  • the hub 1114 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 1110B.
  • the hub 1114 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 1110B, but which is additionally capable of operating as a communication start and/or end point for certain data channels.
  • FIG 11 shows a UE 2000 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 cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehiclemounted 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 (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE.
  • 3GPP 3rd Generation Partnership Project
  • NB-IoT narrow band internet of things
  • MTC machine type communication
  • eMTC enhanced MTC
  • a UE may support device -to-de vice (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle- to-everything (V2X).
  • DSRC Dedicated Short-Range Communication
  • V2V vehicle-to-vehicle
  • V2I vehicle-to-infrastructure
  • V2X vehicle- to-everything
  • 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).
  • 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).
  • the UE 2000 includes processing circuitry 2202 that is operatively coupled via a bus 2204 to an input/output interface 2206, a power source 2208, a memory 2210, a communication interface 2212, and/or any other component, or any combination thereof.
  • Certain UEs may utilize all or a subset of the components shown in Figure 11. 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 2202 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 2210.
  • the processing circuitry 2202 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 2202 may include multiple central processing units (CPUs).
  • the input/output interface 2206 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 2000.
  • 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 2208 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 2208 may further include power circuitry for delivering power from the power source 2208 itself, and/or an external power source, to the various parts of the UE 2000 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 2208.
  • Power circuitry may perform any formatting, converting, or other modification to the power from the power source 2208 to make the power suitable for the respective components of the UE 2000 to which power is supplied.
  • the memory 2210 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.
  • the memory 2210 includes one or more application programs 2214, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 2216.
  • the memory 2210 may store, for use by the UE 2000, any of a variety of various operating systems or combinations of operating systems.
  • the memory 2210 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
  • HD- DVD high-density digital versatile disc
  • HD- DVD high-density digital versatile disc
  • HD- DVD high-density digital versatile disc
  • HD- DVD high-
  • 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 2210 may allow the UE 2000 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 2210, which may be or comprise a device-readable storage medium.
  • the processing circuitry 2202 may be configured to communicate with an access network or other network using the communication interface 2212.
  • the communication interface 2212 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 2222.
  • the communication interface 2212 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 2218 and/or a receiver 2220 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth).
  • the transmitter 2218 and receiver 2220 may be coupled to one or more antennas (e.g., antenna 2222) and may share circuit components, software or firmware, or alternatively be implemented separately.
  • communication functions of the communication interface 2212 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/intemet 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/intemet 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 2212, 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 to a robotic arm performing a medical procedure according to the received input.
  • 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.
  • loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door/window sensor, a flood/moisture sensor, an electrical door lock, a 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-
  • AR Augmented Reality
  • VR
  • 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 3GPP 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. 12 shows a network node 3000 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 NRNodeBs (gNBs)).
  • APs access points
  • BSs base stations
  • Node Bs Node Bs
  • eNBs evolved Node Bs
  • gNBs NRNodeBs
  • 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
  • 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).
  • MSR multi-standard radio
  • RNCs radio network controllers
  • BSCs base station controllers
  • BTSs base transceiver stations
  • OFDM Operation and Maintenance
  • OSS Operations Support System
  • SON Self-Organizing Network
  • positioning nodes e.g., Evolved Serving Mobile Location Centers (E-SMLCs)
  • the network node 3000 includes a processing circuitry 3302, a memory 3304, a communication interface 3306, and a power source 3308.
  • the network node 3000 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 3000 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 network node 3000 may be configured to support multiple radio access technologies (RATs).
  • RATs radio access technologies
  • some components may be duplicated (e.g., separate memory 3304 for different RATs) and some components may be reused (e.g., a same antenna 3310 may be shared by different RATs).
  • the network node 3000 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 3000, 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 3000.
  • RFID Radio Frequency Identification
  • the processing circuitry 3302 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 3000 components, such as the memory 3304, to provide network node 3000 functionality.
  • the processing circuitry 3302 includes a system on a chip (SOC). In some embodiments, the processing circuitry 3302 includes one or more of radio frequency (RF) transceiver circuitry 3312 and baseband processing circuitry 3314. In some embodiments, the radio frequency (RF) transceiver circuitry 3312 and the baseband processing circuitry 3314 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 3312 and baseband processing circuitry 3314 may be on the same chip or set of chips, boards, or units.
  • SOC system on a chip
  • the processing circuitry 3302 includes one or more of radio frequency (RF) transceiver circuitry 3312 and baseband processing circuitry 3314.
  • the radio frequency (RF) transceiver circuitry 3312 and the baseband processing circuitry 3314 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
  • the memory 3304 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 computerexecutable memory devices that store information, data, and/or instructions that may be used by the processing circuitry 3302.
  • 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 memory 3304 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 3302 and utilized by the network node 3000.
  • the memory 3304 may be used to store any calculations made by the processing circuitry 3302 and/or any data received via the communication interface 3306.
  • the processing circuitry 3302 and memory 3304 is integrated.
  • the communication interface 3306 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 3306 comprises port(s)/terminal(s) 3316 to send and receive data, for example to and from a network over a wired connection.
  • the communication interface 3306 also includes radio front-end circuitry 3318 that may be coupled to, or in certain embodiments a part of, the antenna 3310. Radio front-end circuitry 3318 comprises fdters 3320 and amplifiers 3322.
  • the radio front-end circuitry 3318 may be connected to an antenna 3310 and processing circuitry 3302.
  • the radio front-end circuitry may be configured to condition signals communicated between antenna 3310 and processing circuitry 3302.
  • the radio front-end circuitry 3318 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 3318 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 3320 and/or amplifiers 3322.
  • the radio signal may then be transmitted via the antenna 3310.
  • the antenna 3310 may collect radio signals which are then converted into digital data by the radio front-end circuitry 3318.
  • the digital data may be passed to the processing circuitry 3302.
  • the communication interface may comprise different components and/or different combinations of components.
  • the network node 3000 does not include separate radio front-end circuitry 3318, instead, the processing circuitry 3302 includes radio front-end circuitry and is connected to the antenna 3310.
  • the processing circuitry 3302 includes radio front-end circuitry and is connected to the antenna 3310.
  • all or some of the RF transceiver circuitry 3312 is part of the communication interface 3306.
  • the communication interface 3306 includes one or more ports or terminals 3316, the radio front-end circuitry 3318, and the RF transceiver circuitry 3312, as part of a radio unit (not shown), and the communication interface 3306 communicates with the baseband processing circuitry 3314, which is part of a digital unit (not shown).
  • the antenna 3310 may include one or more antennas, or antenna arrays, configured to send and/or receive wireless signals.
  • the antenna 3310 may be coupled to the radio frontend circuitry 3318 and may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly.
  • the antenna 3310 is separate from the network node 3000 and connectable to the network node 3000 through an interface or port.
  • the antenna 3310, communication interface 3306, and/or the processing circuitry 3302 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.
  • the antenna 3310, the communication interface 3306, and/or the processing circuitry 3302 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 power source 3308 provides power to the various components of network node 3000 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component).
  • the power source 3308 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 3000 with power for performing the functionality described herein.
  • the network node 3000 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 3308.
  • the power source 3308 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.
  • Embodiments of the network node 3000 may include additional components beyond those shown in Figure 12 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.
  • the network node 3000 may include user interface equipment to allow input of information into the network node 3000 and to allow output of information from the network node 3000. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 3000.
  • FIG 13 is a block diagram of a host 4000, which may be an embodiment of the host 1016 of Figure 10, in accordance with various aspects described herein.
  • the host 4000 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 4000 may provide one or more services to one or more UEs.
  • the host 4000 includes processing circuitry 4002 that is operatively coupled via a bus 4004 to an input/output interface 4006, a network interface 4008, a power source 4010, and a memory 4012.
  • processing circuitry 4002 that is operatively coupled via a bus 4004 to an input/output interface 4006, a network interface 4008, a power source 4010, and a memory 4012.
  • 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 11 and 12, such that the descriptions thereof are generally applicable to the corresponding components of host 4000.
  • the memory 4012 may include one or more computer programs including one or more host application programs 4014 and data 4016, which may include user data, e.g., data generated by a UE for the host 4000 or data generated by the host 4000 for a UE.
  • Embodiments of the host 4000 may utilize only a subset or all of the components shown.
  • the host application programs 4014 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 4014 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.
  • the host 4000 may select and/or indicate a different host for over-the- top services for a UE.
  • the host application programs 4014 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.
  • HTTP Live Streaming HLS
  • RTMP Real-Time Messaging Protocol
  • RTSP Real- Time Streaming Protocol
  • MPEG-DASH Dynamic Adaptive Streaming over HTTP
  • FIG 14 is a block diagram illustrating a virtualization environment 5000 in which functions implemented by some embodiments may be virtualized.
  • virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources.
  • 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 5000 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.
  • VMs virtual machines
  • the virtual node does not require radio connectivity (e.g., a core network node or host)
  • the node may be entirely virtualized.
  • Applications 5002 (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.
  • Hardware 5004 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 5006 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 5008A and 5008B (one or more of which may be generally referred to as VMs QQ508), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein.
  • the virtualization layer 5006 may present a virtual operating platform that appears like networking hardware to the VMs QQ508.
  • the VMs QQ508 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 5006.
  • Different embodiments of the instance of a virtual appliance 5002 may be implemented on one or more of VMs QQ508, and the implementations may be made in different ways.
  • NFV network function virtualization
  • 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.
  • a VM QQ508 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 QQ508, and that part of hardware 5004 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 QQ508 on top of the hardware 5004 and corresponds to the application 5002.
  • Hardware 5004 may be implemented in a standalone network node with generic or specific components. Hardware 5004 may implement some functions via virtualization.
  • hardware 5004 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 5010, which, among others, oversees lifecycle management of applications 5002.
  • hardware 5004 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.
  • Figure 15 shows a communication diagram of a host 6002 communicating via a network node 6004 with a UE 6006 over a partially wireless connection in accordance with some embodiments.
  • host 6002 Like host 4000, embodiments of host 6002 include hardware, such as a communication interface, processing circuitry, and memory.
  • the host 6002 also includes software, which is stored in or accessible by the host 6002 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 6006 connecting via an over-the-top (OTT) connection 6050 extending between the UE 6006 and host 6002. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection 6050.
  • OTT over-the-top
  • the network node 6004 includes hardware enabling it to communicate with the host 6002 and UE 6006.
  • connection 6060 may be direct or pass through a core network (like core network 1106 of Figure 10) and/or one or more other intermediate networks, such as one or more public, private, or hosted networks.
  • a core network like core network 1106 of Figure 10
  • intermediate networks such as one or more public, private, or hosted networks.
  • an intermediate network may be a backbone network or the Internet.
  • the UE 6006 includes hardware and software, which is stored in or accessible by UE 6006 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 6006 with the support of the host 6002.
  • 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 6006 with the support of the host 6002.
  • an executing host application may communicate with the executing client application via the OTT connection 6050 terminating at the UE 6006 and host 6002.
  • 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 6050 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 6050 may extend via a connection 6060 between the host 6002 and the network node 6004 and via a wireless connection 6070 between the network node 6004 and the UE 6006 to provide the connection between the host 6002 and the UE 6006.
  • the connection 6060 and wireless connection 6070, over which the OTT connection 6050 may be provided, have been drawn abstractly to illustrate the communication between the host 6002 and the UE 6006 via the network node 6004, without explicit reference to any intermediary devices and the precise routing of messages via these devices.
  • the host 6002 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 6006.
  • the user data is associated with a UE 6006 that shares data with the host 6002 without explicit human interaction.
  • the host 6002 initiates a transmission carrying the user data towards the UE 6006.
  • the host 6002 may initiate the transmission responsive to a request transmitted by the UE 6006.
  • the request may be caused by human interaction with the UE 6006 or by operation of the client application executing on the UE 6006.
  • the transmission may pass via the network node 6004, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step 6012, the network node 6004 transmits to the UE 6006 the user data that was carried in the transmission that the host 6002 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 6014, the UE 6006 receives the user data carried in the transmission, which may be performed by a client application executed on the UE 6006 associated with the host application executed by the host 6002.
  • the UE 6006 executes a client application which provides user data to the host 6002.
  • the user data may be provided in reaction or response to the data received from the host 6002.
  • the UE 6006 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 6006. Regardless of the specific manner in which the user data was provided, the UE 6006 initiates, in step 6018, transmission of the user data towards the host 6002 via the network node 6004.
  • the network node 6004 receives user data from the UE 6006 and initiates transmission of the received user data towards the host 6002.
  • the host 6002 receives the user data carried in the transmission initiated by the UE 6006.
  • factory status information may be collected and analyzed by the host 6002.
  • the host 6002 may process audio and video data which may have been retrieved from a UE for use in creating maps.
  • the host 6002 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights).
  • the host 6002 may store surveillance video uploaded by a UE.
  • the host 6002 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs.
  • the host 6002 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.
  • 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 6002 and/or UE 6006.
  • sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 6050 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 6050 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node 6004. 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 6002.
  • the measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 6050 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.
  • a method performed by a source node of a radio communications system for conditional handover, CHO, for a UE comprising: sending (900) a current session ongoing status or not ongoing status to a target node based on successful CHO execution to the target node.
  • a source node of a radio communications system for conditional handover, CHO, for a UE comprising: processing circuitry configured to perform any of the steps of any of Embodiments 1 to 7; and power supply circuitry configured to supply power to the processing circuitry.
  • E-CGI E-UTRAN CGI en-gNB A gNB acting as a secondary node in an EN-DC scenario (i.e. in a
  • NG Next Generation The interface between NG-RAN and 5GC.

Landscapes

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

Abstract

Un procédé est mis en œuvre par un nœud source d'un système de communication radio pendant un CHO pour un UE. La méthode consiste à envoyer un état de la session en cours, indiquant si la session en cours est en cours ou non, à un nœud cible en fonction de l'exécution réussie du CHO vers le nœud cible. Un nœud source associé comprend un circuit de traitement conçu pour envoyer un état de session en cours à un nœud cible d'après l'exécution réussie du CHO vers le nœud cible, et comprend un circuit d'alimentation configuré pour fournir de l'énergie au circuit de traitement.
PCT/IB2022/062542 2022-01-10 2022-12-20 Gestion basée sur un réseau d'une indication d'état d'une session de qualité d'expérience pendant un transfert conditionnel WO2023131845A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202263298135P 2022-01-10 2022-01-10
US63/298,135 2022-01-10

Publications (1)

Publication Number Publication Date
WO2023131845A1 true WO2023131845A1 (fr) 2023-07-13

Family

ID=84887488

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2022/062542 WO2023131845A1 (fr) 2022-01-10 2022-12-20 Gestion basée sur un réseau d'une indication d'état d'une session de qualité d'expérience pendant un transfert conditionnel

Country Status (1)

Country Link
WO (1) WO2023131845A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023014257A1 (fr) * 2021-08-05 2023-02-09 Telefonaktiebolaget Lm Ericsson (Publ) Maintenance de configuration de qualité d'expérience

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023014257A1 (fr) * 2021-08-05 2023-02-09 Telefonaktiebolaget Lm Ericsson (Publ) Maintenance de configuration de qualité d'expérience

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
ERICSSON: "Control plane handling during the RUDI handover procedure", vol. RAN WG2, no. Chongqing, China; 20191010 - 20191014, 3 October 2019 (2019-10-03), XP051803852, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ran/WG2_RL2/TSGR2_107bis/Docs/R2-1912358.zip R2-1912358 - Control plane handling during RUDI HO.docx> [retrieved on 20191003] *
ERICSSON: "QoE Rel-17 Corrections", vol. RAN WG3, no. Online; 20220509 - 20220519, 26 April 2022 (2022-04-26), XP052142968, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ran/WG3_Iu/TSGR3_116-e/Docs/R3-223051.zip R3-223051 - (CR TS 38.423) QoE Rel-17 Corrections.docx> [retrieved on 20220426] *
HUAWEI: "Further analysis on spec impacts on configuration and reporting", vol. RAN WG3, no. E-meeting; 20210517 - 20210527, 7 May 2021 (2021-05-07), XP052002566, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ran/WG3_Iu/TSGR3_112-e/Docs/R3-212519.zip R3-212519 Further analysis on spec impacts on configuration and reporting.docx> [retrieved on 20210507] *
NOKIA (RAPPORTEUR) ET AL: "Miscellaneous corrections to Mobility Enhancements", vol. RAN WG2, no. Electronic; 20201102 - 20201113, 3 December 2020 (2020-12-03), XP051964840, Retrieved from the Internet <URL:https://ftp.3gpp.org/3guInternal/3GPP_Ultimate_CRPacks/RP-202774.zip 38300_CR0305r1_(Rel-16)_R2-2010717_Stage 2 Mobility.docx> [retrieved on 20201203] *

Similar Documents

Publication Publication Date Title
WO2023014257A1 (fr) Maintenance de configuration de qualité d&#39;expérience
WO2023022642A1 (fr) Signalisation de surchauffe prédite d&#39;ue
WO2023131845A1 (fr) Gestion basée sur un réseau d&#39;une indication d&#39;état d&#39;une session de qualité d&#39;expérience pendant un transfert conditionnel
US20240323995A1 (en) Secondary node requested measurement gaps at secondary node addition
US20240267972A1 (en) Prediction and Proactive Handling of Radio Link Failures
US20240298203A1 (en) Signalling based minimization of drive test configuration availability
US20240172074A1 (en) Handling of User Equipment (UE) Context Information after Inter-System Handover
US20240306038A1 (en) Seamless Broadcast Segments Acquisition during Mobility
WO2023131848A1 (fr) Gestion utilisant ue d&#39;indications d&#39;état de session de qoe pendant un transfert conditionnel
WO2024030063A1 (fr) Procédés, appareil et supports lisibles par ordinateur associés à des informations de qualité d&#39;expérience dans un réseau de communication
WO2024107093A1 (fr) Rapport de qualité d&#39;expérience, et rapport de qualité d&#39;expérience visible de réseau d&#39;accès radio lors de défaillances de la liaison radio dans une double connectivité new radio
WO2024035309A1 (fr) Procédés, appareil et support lisible par ordinateur associés à un changement conditionnel de cellule
WO2024038116A1 (fr) Signalisation d&#39;informations de réalité étendue
WO2023152683A1 (fr) Changement de pscell conditionnel initié par un nœud secondaire
WO2023194968A1 (fr) Liste de rapports d&#39;échec d&#39;établissement de connexion (cef) conditionnelle
WO2024181906A1 (fr) Procédés et appareils pour libérer ou suspendre une ou plusieurs configurations de qualité d&#39;expérience lors d&#39;un transfert entre des technologies d&#39;accès radio
WO2024035287A1 (fr) Évitement de situations de concurrence entre mobilité l1/l2 et l3
WO2024030059A1 (fr) Mesure de qualité d&#39;expérience
WO2024171137A1 (fr) Gestion d&#39;une exécution de reconfiguration conditionnelle
WO2023213984A1 (fr) Configuration de l&#39;ue pour le transfert temporel dans un réseau sans fil tel qu&#39;un réseau non terrestre
WO2024107094A1 (fr) Gestion d&#39;une réception asynchrone d&#39;une configuration de qualité d&#39;expérience dans un nœud maître et un nœud secondaire
WO2023069001A1 (fr) Procédure de reconfiguration dans un réseau de communication sans fil
WO2023073656A1 (fr) Procédés pour la visibilité de ran d&#39;une session d&#39;enregistrement de qoe
WO2023158396A1 (fr) Gestion de multiples versions logicielles d&#39;équipement utilisateur dans une mobilité connectée
WO2024035305A1 (fr) Rapport de réussite de changement ou d&#39;ajout de pscell

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22839474

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE