Method, apparatus and system for user plane reconfiguration during conditional mobility

Abstract

Described herein is a method for supporting a conditional mobility procedure involving a source network element serving a user equipment (UE) and at least one target network element, the method comprising: obtaining a first differential radio resource control (RRC) configuration, the configuration indicates a difference between the RRC configuration of the source network element and the RRC configuration of the target network element; storing the first difference RRC configuration; obtaining a second differential RRC configuration indicating a difference between the RRC configuration of the source network element and the RRC configuration of the target network element after the user plane configuration of the UE has been updated; comparing the obtained second differential RRC configuration with the stored first differential RRC configuration to determine whether the first differential RRC configuration and the second differential RRC configuration are the same; based on determining that the first and second differential RRC configurations are different: transmitting an RRC reconfiguration message to the UE; and based on determining that the first and second differential RRC configurations are the same: skipping transmission of the RRC reconfiguration message to the UE.

Description

Technical Field

[0001] The present disclosure relates to conditional mobility, and in particular to methods, devices and systems for user plane reconfiguration during conditional mobility procedures (such as conditional handover (CHO), conditional PSCell change (CPC), conditional PSCell addition (CPA), etc.). Background Art

[0002] Any discussion of the background art throughout the specification should not be considered as an admission that this art is widely known or forms part of the common general knowledge in the field.

[0003] Broadly speaking, the Conditional Handover (CHO) procedure was introduced in 3rd Generation Partnership Project (3GPP) Release 16 to improve mobility robustness. In case of CHO, the network may prepare multiple target cells, where each conditional handover reconfiguration is associated with a CHO execution condition to be evaluated by the user equipment (UE). The CHO execution condition may refer to a measurement ID that associates the measurement object with a reporting configuration and may be configured by the source gNB. The reporting configuration may typically define measurement events (e.g., A3 or A5) that may trigger reporting of the configured measurements. The UE may also configure the same measurement event, which will trigger CHO execution when the configured measurement configuration is met. Whenever a CHO execution condition is met, the corresponding target configuration is selected and a handover towards the selected target cell is performed.

[0004] In Release 16, another procedure called Conditional PSCell (primary-secondary cell, which can also be considered as spCell of a secondary cell group (SCG)) Change (CPC) was also specified, but it is mainly used for intra-SN (secondary node) scenarios. Later, CPC has been extended in Release 17 for inter-SN scenarios, where it usually has two flavors, namely: CPC initiated by MN (primary node) and CPC initiated by SN.

[0005] Some additional enhancements proposed for the mobility work items in Release 18 also mention the following goals, including specifying mechanisms and procedures for NR-DC (New Radio - Dual Connectivity), where cell groups are selectively activated (at least for secondary cell groups (SCGs)) via L3 enhancements; to allow subsequent cell group changes after changing the CG (cell group) without reconfiguring and re-initiating CPC or CPA (conditional PSCell addition).

[0006] Generally speaking, in CHO or CPC / CPA, the target node can generate a complete or differential radio resource control (RRC) configuration for a candidate target primary cell (PCell) or PSCell, respectively. In the case of a complete configuration, the UE will perform the steps defined in the standard, including releasing / clearing some current dedicated radio configurations and all current public radio configurations, and applying the default medium access control (MAC) cell group configuration and service radio bearer (SRB) configuration. On the other hand, in the case of a differential configuration, the configuration of the candidate target cell only contains the parameters that need to be modified (subject to changes) compared to the configuration of the current source cell. In this way, the size of the differential configuration can be much smaller than the size of the complete configuration, which will then significantly reduce the overhead on the radio interface.

[0007] When the user plane configuration of the UE is updated (e.g., configuring new bearers, QoS flows created for RRC connections, etc.), an RRC reconfiguration (e.g., for a modified data radio bearer (DRB) configuration) will have to be provided to the UE. As an example, the delay in activating the bearer is the time that would be taken for this signaling process in a normal scenario. In the case of a classic handover, the reconfiguration needs to be triggered after the handover is performed, where the delay will also include the handover execution time. On the other hand, in the case of a conditional reconfiguration scenario, if the DRB configuration is updated towards the UE for the current cell, the conditional reconfiguration also needs to be modified to reflect this new DBR change so that after the CHO (or CPC / CPA) is performed, the configuration is aligned at the UE and the target node. However, this will introduce additional delays in preparing the target configurations for this change and including them together with the DRB configuration for the serving cell.

[0008] Thus, broadly speaking, the problem is that for each DRB configuration update (e.g., addition, deletion, modification), or more generally, for each user plane configuration update, those reconfigurations towards the UE will be repeated. The problem will be particularly exacerbated for selective activation, where the prepared cell is maintained even after a conditional cell change has been performed.

[0009] In summary, it can generally be considered that there are the following two problems associated with conventional technology, namely:

[0010] Increased signaling latency and internal signaling overhead for user plane configuration updates (e.g., DRB configuration changes) during the CHO / CP(A)C execution window due to the need to update across multiple target cells before propagating the user plane configuration updates (e.g., DRB configuration changes) to the UE; and

[0011] For CP(A)C, the reconfiguration after each DRB change at the SCG seems to counteract the general goal of allowing subsequent cell group changes after changing CG without reconfiguration and re-initiating CPC / CPA.

[0012] Therefore, there is a need to propose new mechanisms / techniques for supporting conditional mobility use cases (e.g., CHO, CPC / CPA, etc.) in order to address some or all of the above-mentioned issues, especially in an efficient, flexible and reliable manner. Summary of the invention

[0013] According to one aspect of the present disclosure, a method for supporting a conditional mobility procedure is provided, the conditional mobility procedure involving a source network element and at least one target network element, the source network element serving a user equipment (UE), the method comprising: obtaining a first differential radio resource control (RRC) configuration, the first differential RRC configuration indicating a difference between an RRC configuration of a source network element and an RRC configuration of a target network element; storing a first differential RRC configuration; obtaining a second differential RRC configuration, the second differential RRC configuration indicating a difference between the RRC configuration of the source network element and the RRC configuration of the target network element after the user plane configuration of the UE has been updated; comparing the obtained second differential RRC configuration with the stored first differential RRC configuration to determine whether the first differential RRC configuration is the same as the second differential RRC configuration; Based on determining that the first differential RRC configuration is different from the second differential RRC configuration: transmitting an RRC reconfiguration message to the UE; and Based on determining that the first differential RRC configuration is the same as the second differential RRC configuration: The transmission of the RRC reconfiguration message to the UE is skipped.

[0014] In some examples, the first differential RRC configuration is stored by the source network element; and the first differential RRC configuration and the second differential RRC configuration are compared by the source network element.

[0015] In some examples, obtaining the first RRC configuration includes: transmitting, by the source network element to the target network element, a first request message indicating a conditional mobility procedure; and A first delta RRC configuration is received by a source network element from a target network element.

[0016] In some examples, obtaining the second RRC configuration includes: transmitting, by the source network element to the target network element, a second request message indicating an update of a user plane configuration of the UE; and A second delta RRC configuration is received by the source network element from the target network element.

[0017] In some examples, Based on determining that the first differential RRC configuration is different from the second differential RRC configuration: transmitting, by the source network element to the UE, an RRC reconfiguration message for conveying the RRC configuration of the target network element for the conditional mobility procedure regarding the updated user plane configuration; and Based on determining that the first differential RRC configuration is the same as the second differential RRC configuration: Transmission of an RRC reconfiguration message to the UE is skipped by the source network element.

[0018] In some examples, the first differential RRC configuration is stored by the target network element; and the first differential RRC configuration and the second differential RRC configuration are compared by the target network element.

[0019] In some examples, obtaining the first RRC configuration includes: receiving, by the target network element from the source network element, a first request message indicating a conditional mobility procedure; and A first differential RRC configuration is generated by the target network element.

[0020] In some examples, obtaining the second RRC configuration includes: receiving, by the target network element from the source network element, a second request message indicating an update of a user plane configuration of the UE; and A second delta RRC configuration is generated by the target network element based on the updated user plane configuration.

[0021] In some examples, Based on determining that the first differential RRC configuration is different from the second differential RRC configuration: transmitting, by the target network element to the source network element, a second differential RRC configuration; and transmitting, by the source network element to the UE, an RRC reconfiguration message for conveying the RRC configuration of the target network element for the conditional mobility procedure regarding the updated user plane configuration; and Based on determining that the first differential RRC configuration is the same as the second differential RRC configuration: transmitting, by the target network element, information indicating that the first differential RRC configuration and the second differential RRC configuration are the same for the source network element, Transmission of an RRC reconfiguration message to the UE is skipped by the source network element based on the information indicating that the first differential RRC configuration is the same as the second differential RRC configuration.

[0022] In some examples, the first differential RRC configuration being the same as the second differential RRC configuration is indicated by at least one of: a flag, a value, a bitmap, or an absence of transmission of the second differential RRC configuration or a portion thereof.

[0023] In some examples, the conditional mobility procedure involves a conditional handover (CHO) procedure.

[0024] In some examples, the source network element and the target network element are each gNBs.

[0025] In some examples, the conditional mobility procedure involves a conditional PSCell change (CPC) procedure or a conditional PSCell addition (CPA) procedure.

[0026] In some examples, the source network element is a master node (MN) and the target network element is a slave node (SN).

[0027] According to another aspect of the present disclosure, a communication system is provided, including a source network element, at least one target network, and a user equipment (UE) served by the source network element, wherein the communication system is configured to perform the method disclosed in the present disclosure.

[0028] According to yet another aspect of the present disclosure, there is provided a source network element configured to support a conditional mobility procedure involving at least one target network element and a user equipment (UE) served by the source network element, the source network element comprising: at least one processor; and At least one memory storing instructions, which when executed by at least one processor, cause the source network element to at least: obtaining a first differential radio resource control (RRC) configuration, the first differential RRC configuration indicating a difference between an RRC configuration of a source network element and an RRC configuration of a target network element; storing a first differential RRC configuration; obtaining a second differential RRC configuration, the second differential RRC configuration indicating a difference between the RRC configuration of the source network element and the RRC configuration of the target network element after the user plane configuration of the UE has been updated; comparing the obtained second differential RRC configuration with the stored first differential RRC configuration to determine whether the first differential RRC configuration is the same as the second differential RRC configuration; Based on determining that the first differential RRC configuration is different from the second differential RRC configuration: transmitting an RRC reconfiguration message to the UE; and Based on determining that the first differential RRC configuration is the same as the second differential RRC configuration: The transmission of the RRC reconfiguration message to the UE is skipped.

[0029] In some examples, the source network element obtains the first differential RRC configuration by receiving the first differential RRC configuration from the target network element in response to a first request message indicating a conditional mobility procedure being sent to the target network element; and the source network element obtains the second differential RRC configuration by receiving the second differential RRC configuration from the target network element in response to a second request message indicating a conditional mobility procedure being sent to the target network element.

[0030] In some examples, when the conditional mobility process involves a conditional handover (CHO) process, the source network element is a gNB, and the first conditional mobility process request and the second conditional mobility process request are conditional handover requests; or when the conditional mobility process involves a conditional PSCell change (CPC) process or a conditional PSCell addition (CPA) process, the source network element is a master node (MN), and the first conditional mobility process request and the second conditional mobility process request are SN addition requests.

[0031] According to another aspect of the present disclosure, a target network element is provided, configured to support a conditional mobility procedure, the conditional mobility procedure involving a source network element and a target network element, the source network element serving a user equipment (UE), the target network element comprising: at least one processor; and At least one memory stores instructions, which, when executed by at least one processor, cause the target network element to at least: obtaining a first differential radio resource control (RRC) configuration, the first differential RRC configuration indicating a difference between an RRC configuration of a source network element and an RRC configuration of a target network element; storing a first differential RRC configuration; obtaining a second differential RRC configuration indicating a difference between the RRC configuration of the source network element and the RRC configuration of the target network element after the user plane configuration of the UE has been updated; comparing the obtained second differential RRC configuration with the stored first differential RRC configuration to determine whether the first differential RRC configuration is the same as the second differential RRC configuration; Based on determining that the first differential RRC configuration is different from the second differential RRC configuration: transmitting a second differential RRC configuration to the source network element for enabling the source network element to transmit an RRC reconfiguration message to the UE; and Based on determining that the first differential RRC configuration is the same as the second differential RRC configuration: Information indicating that the first differential RRC configuration and the second differential RRC configuration are identical to the source network element enables transmission of an RRC reconfiguration message from the source network element to the UE to be skipped.

[0032] In some examples, the target network element obtains the first differential RRC configuration by: generating the first differential RRC configuration by the target network element based on a received first request message indicating a conditional mobility procedure; and the target network element obtains the second differential RRC configuration by: generating the second differential RRC configuration by the target network element based on a received second request message indicating a conditional mobility procedure.

[0033] In some examples, when the conditional mobility procedure involves a conditional handover (CHO) procedure, the target network element is a gNB, and the first conditional mobility procedure request and the second conditional mobility procedure request are conditional handover requests; or when the conditional mobility procedure involves a conditional PSCell change (CPC) procedure or a conditional PSCell addition (CPA) procedure, the target network element is a secondary node (SN), and the first conditional mobility procedure request and the second conditional mobility procedure request are SN addition requests.

[0034] According to another aspect of the present disclosure, there is provided a source network element configured to support a conditional mobility procedure involving at least one target network element and a user equipment (UE) served by the source network element, the source network element comprising: at least one processor; and At least one memory storing instructions, which when executed by at least one processor, cause the source network element to at least: transmitting a first request message indicating a conditional mobility procedure to a target network element; receiving, in response to the first conditional mobility procedure request, a first differential RRC configuration from a target network element; transmitting, based on the received first differential RRC configuration, a first RRC reconfiguration message to the UE, conveying the RRC configuration of the target network element for the conditional mobility procedure; sending, in response to updating a user plane configuration of the UE, a second request message indicating a conditional mobility procedure to the target network element; When a second delta RRC configuration is received from the target network element in response to the second conditional mobility procedure request: transmitting a second RRC reconfiguration message to the UE; and When receiving, in response to the second conditional mobility request, information from the target network element indicating that the differential RRC configuration has not changed: Transmission of the second RRC reconfiguration message to the UE is skipped.

[0035] According to some example embodiments, there is provided a computer program comprising instructions for causing an apparatus or a system to execute the method disclosed in the present disclosure.

[0036] According to some example embodiments, a memory is further provided, storing computer-readable instructions for causing an apparatus or system to execute the method disclosed in the present disclosure.

[0037] Furthermore, according to some example embodiments, there is provided a source network element configured to support a conditional mobility procedure involving at least one target network element and a user equipment (UE) served by the source network element, the source network element comprising respective suitable components configured to perform respective steps as disclosed in the present disclosure.

[0038] Similarly, according to some example embodiments, there is also provided a target network element configured to support a conditional mobility procedure involving a source network element and a target network element, the source network element serving a user equipment (UE), the target network element comprising corresponding suitable components configured to perform corresponding steps as disclosed in the present disclosure.

[0039] In addition, according to some other example embodiments, for example, a computer program product for a wireless communication device including at least one processor is provided, comprising a software code portion for executing the corresponding steps disclosed in the present disclosure when the product is run on the device. The computer program product may include a computer-readable medium on which the software code portion is stored. In addition, the computer program product may be directly loaded into the internal memory of the computer and / or may be transmitted via a network by means of at least one of an upload, download, and push process.

[0040] Although some example embodiments will be described herein with particular reference to the above-mentioned application, it will be appreciated that the present disclosure is not limited to this field of use and is applicable in a wider context.

[0041] Note that it should be understood that the method according to the present disclosure relates to a method of operating an apparatus (or system) according to the above-described example embodiments and variations thereof, and that corresponding statements made about the apparatus (or system) are equally applicable to the corresponding method, and vice versa, so that similar descriptions may be omitted for the sake of brevity. In addition, the above aspects may be combined in many ways, even if not explicitly disclosed. The skilled person will understand that these combinations of various aspects and features / steps are possible unless they produce contradictions that are explicitly excluded.

[0042] Implementation of the disclosed apparatus may include the use of, but is not limited to, one or more processors, one or more application specific integrated circuits (ASICs), and / or one or more field programmable gate arrays (FPGAs). Implementation of the apparatus may also include the use of other conventional and / or custom hardware, such as a software programmable processor, such as a graphics processing unit (GPU) processor.

[0043] Other and further example embodiments of the present disclosure will become apparent during the course of the following discussion and by reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Example embodiments of the present disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0045] Figure 1 schematically illustrates an example of a conditional handover (CHO) signaling / message flow diagram according to some examples of the present disclosure;

[0046] Figure 2 schematically illustrates an example of a conditional PSCell change / addition (CPC / CPA) signaling / message flow diagram according to some examples of the present disclosure;

[0047] Figure 3 Schematically illustrates an example of configuration update for CHO according to some examples of the present disclosure;

[0048] Figure 4 Schematically illustrates an example of configuration update for CPC / CPA according to some examples of the present disclosure;

[0049] Figure 5 Schematically illustrates an example of configuration update for CHO according to some example embodiments of the present disclosure;

[0050] Figure 6 Schematically illustrates an example of configuration update for CPC / CPA according to some example embodiments of the present disclosure;

[0051] Figure 7Schematically illustrates another example of configuration update for CHO according to some example embodiments of the present disclosure;

[0052] Figure 8 Schematically illustrates another example of configuration update for CPC / CPA according to some example embodiments of the present disclosure;

[0053] Fig. 9A and Fig. 9B schematically illustrates an example of a communication network / system architecture according to some example embodiments of the present disclosure; and

[0054] Fig.10 Examples of implementations of devices according to some example embodiments of the present disclosure are schematically shown. DETAILED DESCRIPTION

[0055] Note that, unless otherwise specified, the same or similar reference numerals used in the drawings of the present disclosure may indicate the same or similar elements. Similarly, unless otherwise specified, the same or similar messages (and the contents included therein) used in the drawings of the present disclosure may indicate the same or similar messages (and the contents therein), so that their repeated descriptions may be omitted for the sake of brevity.

[0056] However, in the following, different exemplary embodiments will be described using a communication network architecture based on 3GPP standards for communication networks such as 5G / NR as an example of an example communication network to which the embodiments may be applied, without limiting the embodiments to such an architecture. It is obvious to a person skilled in the art that the embodiments may also be applied to other kinds of communication networks in which the mobile communication principles are integrated with D2D (device to device) or V2X (vehicle to everything) configurations, such as SL (side link), e.g. Wi-Fi, Worldwide Interoperability for Microwave Access (WiMAX), Personal Communications Service (PCS), Wideband Code Division Multiple Access (WCDMA), systems using ultra-wideband (UWB) technology, mobile ad hoc networks (MANET), wired access, etc. In addition, without loss of generality, the description of some examples of the embodiments relates to mobile communication networks, but the principles of the present disclosure can be extended and applied to any other type of communication network, such as a wired communication network.

[0057] The following examples and embodiments are to be understood as illustrative examples only. Although the specification may refer to "one", "an" or "some" examples or embodiments in several places, this does not necessarily mean that each such reference relates to the same example or embodiment, or that a feature applies only to a single example or embodiment. Individual features of different embodiments may also be combined to provide other embodiments. In addition, terms like "include" and "comprising" should be understood as not limiting the described embodiments to consist only of those features that have been mentioned; such examples and embodiments may also contain features, structures, units, modules, etc. that have not been specifically mentioned.

[0058] The basic system architecture of a (tele)communication network including a mobile communication system (in which some examples of the embodiments apply) may include the architecture of one or more communication networks (including a radio access network subsystem and a core network). Such an architecture may include one or more communication network control elements or functions, access network elements, radio access network elements, access service network gateways or base station transceivers, such as base stations (BS), access points (AP), node Bs (NBs), eNBs or gNBs, distributed units (DUs) or centralized / central units (CUs), which control the corresponding coverage areas or cells, and one or more communication stations (such as communication elements or functions, such as user equipment or terminal equipment, such as user equipment (UE), or another device with similar functions, such as a modem chipset, chip, module, etc., which may also be part of a station, element, function or application capable of communication, such as a UE, an element or function that can be used in a machine-to-machine communication architecture, or attached as a separate element to such an element, a function or application capable of communication, etc.) can communicate with it via one or more communication beams via one or more channels for sending several types of data in multiple access domains. Furthermore, core network elements or network functions may be included, such as gateway network elements / functions, mobility management entities, mobile switching centers, servers, databases, etc.

[0059] The following description may provide further details of alternatives, modifications and variations: The gNB includes, for example, a node that provides NR user plane and control plane protocol terminations to the UE, and is connected to the 5GC via an NG interface, for example in accordance with 3GPP TS 38.300 V16.6.0 (2021-06) section 3.2 incorporated by reference.

[0060] The gNB Central Unit (gNB-CU) includes logical nodes for hosting, for example, the RRC, SDAP and PDCP protocols of the gNB or controlling the operation of one or more gNB-DUs. The gNB-CU terminates the F1 interface connected to the gNB-DU.

[0061] The gNB distributed unit (gNB-DU) includes logical nodes such as hosting the RLC, MAC and PHY layers of a gNB or en-gNB, and its operation is partially controlled by the gNB-CU. One gNB-DU supports one or more cells. One cell is supported by only one gNB-DU. The gNB-DU terminates the F1 interface with the gNB-CU.

[0062] The gNB-CU-Control Plane (gNB-CU-CP) comprises, for example, a logical node hosting the RRC and control plane parts of the PDCP protocol for a gNB-CU of an en-gNB or gNB. The gNB-CU-CP terminates the E1 interface with the gNB-CU-UP and the F1-C interface with the gNB-DU.

[0063] The gNB-CU-User Plane (gNB-CU-UP) includes, for example, a logical node hosting, for example, the user plane part of the PDCP protocol for the gNB-CU of the en-gNB and the user plane parts of the PDCP protocol and the SDAP protocol for the gNB-CU of the gNB. The gNB-CU-UP terminates the E1 interface connected to the gNB-CU-CP and the F1-U interface connected to the gNB-DU, for example, according to 3GPP TS 38.401 V16.6.0 (2021-07) section 3.1 incorporated by reference.

[0064] Different functional splits between central and distributed units are possible, e.g. called options: Option 1 (similar split to 1A): ○ The functional split in this option is similar to 1A architecture in DC. RRC is in the central unit. PDCP, RLC, MAC, physical layer and RF are in distributed units. Option 2 (similar to 3C split): ○ The functional split in this option is similar to the 3C architecture in DC. RRC and PDCP are in the central unit. RLC, MAC, physical layer, and RF are in the distributed unit. Option 3 (split within RLC): ○ Low RLC (partial functionality of RLC), MAC, physical layer and RF are in distributed units. PDCP and higher RLC (another part of the RLC functionality) are in the central unit. Option 4 (RLC-MAC Split): o MAC, physical layer and RF are in distributed units. PDCP and RLC are in a central unit. Or, for example, according to 3GPP TR 38.801 V14.0.0 (2017-03) section 11, incorporated by reference.

[0065] gNB supports different protocol layers, for example, Layer 1 (L1) - physical layer.

[0066] Layer 2 (L2) of NR is divided into the following sublayers: Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), and Service Data Adaptation Protocol (SDAP), where for example: ○The physical layer provides the transport channel to the MAC sublayer; ○The MAC sublayer provides logical channels to the RLC sublayer; ○ The RLC sublayer provides RLC channels to the PDCP sublayer; ○ The PDCP sublayer provides radio bearer to the SDAP sublayer; ○The SDAP sublayer provides QoS flows to 5GC; ○Comp. refers to header compression and Segm. refers to segmentation; ○Control channels include (BCCH, PCCH).

[0067] Layer 3 (L3) includes, for example, Radio Resource Control (RRC), for example according to Section 6 of 3GPP TS 38.300 V16.6.0 (2021-06), incorporated by reference.

[0068] A RAN (Radio Access Network) node or network node (e.g. a gNB, a base station, a gNB CU or a gNB DU or part thereof) may be implemented using, for example, a device having at least one processor and / or at least one memory having computer-readable instructions (computer program) configured to support and / or provide and / or process CU and / or DU related functions and / or features, and / or at least one protocol (sub) layer of a RAN (Radio Access Network), such as layer 2 and / or layer 3.

[0069] The gNB CU and gNB DU parts may, for example, be co-located or physically separated. The gNB DU may even be further split into, for example, two parts, for example, one part including a processing device and one part including an antenna. The central unit (CU) may also be referred to as BBU / REC / RCC / C-RAN / V-RAN, O-RAN or a part thereof. The distributed unit (DU) may also be referred to as RRH / RRU / RE / RU or a part thereof. Hereinafter, in various example embodiments of the present disclosure, the CU-CP (or more generally, CU) may also be referred to as a (first) network node that supports at least one of the central unit control plane functions or the layer 3 protocol of the radio access network; and similarly, the DU may be referred to as a (second) network node that supports at least one of the distributed unit functions or the layer 2 protocol of the radio access network.

[0070] A gNB-DU supports one or more cells and can thus be used, for example, as a serving cell for a user equipment (UE).

[0071] User equipment (UE) may include a wireless or mobile device, a device having a radio interface that interacts with a RAN (Radio Access Network), a smart phone, a vehicle-mounted device, an IoT device, an M2M device, etc. Such a UE or device may include: at least one processor; and at least one memory including computer program code; wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the device to at least perform certain operations, such as an RRC connection to the RAN. The UE is, for example, configured to generate a message (e.g., including a cell ID) to be transmitted to the RAN via radio (e.g., to reach and communicate with a serving cell). The UE may generate, send and receive an RRC message containing one or more RRC PDUs (packet data units).

[0072] The UE may have different states (e.g., according to sections 42.1 and 4.4 of 3GPP TS 38.331 V16.5.0 (2021-06) incorporated by reference).

[0073] For example, when an RRC connection has been established, the UE is in the RRC_CONNECTED state or the RRC_INACTIVE state.

[0074] In the RRC_CONNECTED state, the UE may: ○Store AS context; ○Transmit unicast data to / from UE; o monitoring a control channel associated with a shared data channel to determine whether data is scheduled for the data channel; ○Provide channel quality and feedback information; ○Perform neighbor cell measurements and measurement reporting.

[0075] The RRC protocol includes the following main functions: ○RRC connection control; ○ Measurement configuration and reporting; o Establishment / modification / release of measurement configurations (e.g., intra-frequency, inter-frequency and inter-RAT measurements); ○Establish and release measurement gaps; ○Measurement report.

[0076] The general functionality and interconnection of the described elements and functions (which also depends on the actual network type) are known to those skilled in the art and are described in the corresponding specifications, so for the sake of brevity, a detailed description thereof may be omitted herein. However, it is to be noted that several additional network elements and signaling links may be used for communication to or from elements, functions or applications, such as communication endpoints, communication network control elements (such as servers, gateways, radio network controllers), and other elements of the same or other communication networks in addition to those described in detail below herein.

[0077] The communication network architecture considered in the example of the embodiment is also capable of communicating with other networks, such as a public switched telephone network or the Internet. The communication network is also capable of supporting cloud services for virtual network elements or their functions, wherein it should be noted that the virtual network portion of the telecommunications network can also be provided by non-cloud resources, such as an internal network, etc. It should be understood that the network elements and / or corresponding functions of the access system, core network, etc. can be implemented by using any node, host, server, access node or entity, etc. suitable for such use. In general, the network functions can be implemented as network elements on dedicated hardware, software instances running on dedicated hardware, or virtualized functions instantiated on an appropriate platform (e.g., cloud infrastructure).

[0078] In addition, network elements (such as communication elements, such as UE, terminal equipment), control elements or functions (such as access network elements, such as base stations / BS, gNB, radio network controllers), core network control elements or functions (such as gateway elements) or other network elements or functions, as well as any other elements, functions or applications described herein, can be implemented by software (for example, by a computer program product for a computer) and / or by hardware. In order to perform its corresponding processing, the corresponding device, node, function or network element may include several components, modules, units, components, etc. (not shown) required for control, processing and / or communication / signaling functions. Such components, modules, units and components may include, for example, one or more processors or processor units including one or more processing parts for executing instructions and / or programs and / or for processing data, storage or memory units or components (e.g. ROM, RAM, EEPROM, etc.) for storing instructions, programs and / or data for use as working areas for processors or processing parts, etc., input or interface components (e.g. floppy disks, CD-ROMs, EEPROMs, etc.) for inputting data and instructions by software, user interfaces (e.g. screens, keyboards, etc.) for providing monitoring and manipulation possibilities to the user, other interfaces or components for establishing links and / or connections under the control of the processor units or parts (e.g. wired and wireless interface components, radio interface components including, for example, antenna units, etc., components for forming a radio communication part, etc.), etc., wherein the corresponding components forming interfaces such as a radio communication part may also be located at a remote site (e.g. a radio head or a radio station, etc.). It should be noted that in this specification, a processing part should not only be considered to mean a physical part of one or more processors, but also a logical division of the referenced processing tasks performed by one or more processors. It should be understood that according to some examples, a so-called "liquid" or flexible network concept may be adopted, in which the operations and functions of a network element, a network function, or another entity of the network may be performed in a flexible manner in different entities or functions, such as in a node, a host, or a server. In other words, the "division of labor" between the network elements, functions, or entities involved may vary depending on the situation.

[0079] As described above, a conditional handover (CHO) procedure has been introduced to improve mobility robustness. In particular, in the case of CHO, the network may prepare multiple target cells, where each conditional handover reconfiguration is associated with a CHO execution condition evaluated by the UE. The CHO execution condition may refer to a measurement ID that associates a measurement object with a reporting configuration and may be configured by the source gNB. The reporting configuration may typically define a measurement event (e.g., A3 or A5) that may trigger the reporting of the configured measurements. The UE may also configure the same measurement event, which will trigger CHO execution when the configured measurement configuration is met. Whenever the CHO execution condition is met, the corresponding target configuration is selected and a handover is performed towards the selected target cell. In short, the CHO procedure may generally be viewed as being designed so that the UE can autonomously perform a handover without the serving cell triggering a handover (HO) execution after receiving a measurement report from the UE.

[0080] In particular, the main steps of this CHO process can be summarized as follows.

[0081] In step S101 , the UE sends a measurement report identifying potential neighboring cells for handover.

[0082] Subsequently, in steps S102-S108, in particular in response to the measurements received in step S101, the source gNB determines that a target cell with CHO should be prepared for the UE. Therefore, the source gNB sends a conditional handover request (or the like) to multiple target gNBs. In each CHO request message, the source gNB indicates the target PCell to be prepared by the target gNB. The target gNB performs admission control and sends a handover request ACK for the requested PCell and the related conditional configuration as a response to the handover request.

[0083] In step S109, the source gNB sends an RRC reconfiguration with conditional configuration related to CHO to the UE.

[0084] Then, as shown in steps S110-S111, the UE evaluates the CHO condition and performs conditional configuration for CHO for which the condition is maintained; and as shown in steps S111-S114, performs CHO towards the target cell controlled by the target gNB.

[0085] In step S115, the target gNB indicates to the source gNB that the handover is successful.

[0086] Then, as illustrated in step S116 , user plane procedures such as data forwarding and path switching are completed thereafter.

[0087] Similarly, Figure 2is a schematic high-level illustration of the main signaling / message transmission steps of the Conditional PSCell Change / Add (CPC / CPA) process, which will now be described in more detail below. Specifically, Figure 2 The example shown can be understood as a CPC / CPA process initiated by a secondary node (SN). As can be understood and appreciated by those skilled in the art, an SN can generally be used to refer to a radio access node that does not have a control plane connection to a core network and is used to provide additional resources to a UE (e.g., deployed in a multi-RAT (radio access technology) dual connection (MR-DC) technology / system). Depending on various possible technologies, the SN can be implemented as an en-gNB (e.g., in EN-DC, i.e., E-UTRA-NR dual connection), a secondary ng-eNB (e.g., in NE-DC, i.e., NR-E-UTRA dual connection), a secondary gNB (e.g., in NR-DC and NGEN-DC), and the like. Accordingly, a master node (MN) can generally be used to refer to a radio access node that provides a control plane connection to a core network (e.g., deployed in an MR-DC technology / system). Depending on various possible technologies, the MN can be implemented as a master eNB (e.g., in EN-DC), a master ng-eNB (e.g., in NGEN-DC), a master gNB (e.g., in NR-DC and NE-DC), and so on.

[0088] Reference now Figure 2 In step S201, the source SN indicates to the MN the IDs of the target SNs to be contacted to prepare (multiple) target PSCells. The source SN may propose a list of PSCells to be prepared by each target SN and provide CPC execution conditions for each proposed target PSCell.

[0089] In steps S202 and S203, the MN sends an add request, including the PSCell suggested by the source SN, etc., to each target SN indicated by the source SN, for example.

[0090] Subsequently, in steps S204 and S205, the target SN may decide a candidate target PSCell to be prepared in a suggestion list of PSCells to be prepared.

[0091] In steps S206 and S207, the target SN sends the CPC configuration for each prepared target PSCell and the corresponding ID(s) of the prepared target PSCell(s) to the MN.

[0092] Then in step S208, the MN sends a (conditional) (re)configuration to the UE (eg, in any suitable message), which includes CPC configuration(s) of the candidate target PSCell(s) and corresponding CPC execution condition(s).

[0093] In step S209, the UE sends a corresponding message to the MN confirming the receipt of the conditional configuration (eg, as an RRC Reconfiguration Complete message or in any other suitable message form / format), and the MN then confirms the SN change preparation to the source SN in step S210.

[0094] Later, as shown in step S211, the UE evaluates the CPC execution condition of the prepared target PSCell(s).

[0095] When the CPC execution condition of the PSCell candidate in the target SN1 is met, as shown in step S212, the UE may send a message indicating the execution of CPC configuration to the MN in step S13. The message may include the SN RRC Reconfiguration Complete sent (by the MN) to the target SN1 in step S214.

[0096] Finally, as those skilled in the art can understand and appreciate, the UE can perform a random access procedure as shown in step S215.

[0097] As already noted above, when the user plane configuration of the UE is updated (e.g., new bearers are configured, QoS flows created for a Radio Resource Control (RRC) connection, etc.), an RRC reconfiguration (e.g., for a modified DRB configuration) will have to be provided to the UE, which may however introduce undesirable signaling delays and internal signaling overhead due to the fact that the update(s) (e.g., DRB configuration changes) will typically need to be across multiple target cells before being propagated towards the UE.

[0098] For example, Figure 3 An example is schematically shown where in the case of CHO, after each update of the DRB configuration etc. (as illustrated in steps S308 and S309), radio signaling of steps S315 and S316 will have to be sent over the air between the UE and the source gNB.

[0099] More specifically, after the release or establishment of the PDU session (step S308), the DRB configuration of the UE is updated by the source cell (gNB) (step S309). As a next step S310, the DRB configuration change is indicated to all nodes controlling the candidate cell. The node controlling the candidate cell updates the UE DRB configuration (as illustrated in steps S311 and S312) and sends the configuration back to the UE (steps S313 and sS314). As described above, this update of the configuration will be subject to delays and additional signaling will also be required; therefore, the UE will need to be reconfigured after the initial configuration.

[0100] For the case of CPC updates (or, in some possible cases, CPA scenarios) where there is an interaction between the source MN and the target SN, similar issues / arguments often exist, such as Figure 4 That is, in the case of CPC, after each update of the DRB configuration, the radio signaling of step S415 and step S416 must be sent over the air between the UE and the source MN, resulting in signaling delay and overhead. It is worth noting that due to Figure 4 The main steps shown in the example look more or less like Figure 3 The steps shown in FIG. 1 (except for the different network elements involved and thus the different messaging / signaling exchanged between those network elements) are not described in detail for the sake of brevity. Figure 4 The corresponding steps.

[0101] For the sake of completeness, it is also noted that some other possible (conventional) techniques may also present various problems or issues, such as requiring indirect coordination between source and target network elements.

[0102] In view of this, the present disclosure generally proposes mechanisms / techniques for supporting such conditional mobility use cases (e.g., CHO, CPC / CPA, etc.), in particular in an efficient, flexible, yet reliable manner. Broadly speaking, in order to overcome the excessive signaling (which is caused by the update of user plane configuration, such as DRB update, as described above), it is generally proposed to compare the newly created delta configuration of the candidate cell in the target node with the initial delta configuration before generating the newly created delta configuration.

[0103] For ease of understanding, Tables 1 and 2 schematically illustrate exemplary (non-limiting) RRC configurations for UEs by source and target nodes (shown in full or differential format) before and after possible DRB updates, respectively (which are used only as one possible non-limiting example for illustrating user plane configuration). It is worth noting that in this example, DRB2 and QoS flow 2 correspondingly mapped to DRB2 are deleted / removed. Therefore, as can be understood and appreciated by those skilled in the art, the (target) differential configuration (as shown in the third column of the two tables) generally only indicates information elements (IEs) that are different from the source configuration. Table 1: RRC configuration before DRB update Table 2: RRC configuration after DRB update

[0104] As can be seen from the above table, before a possible DRB update (Table 1), many configurations (as exemplarily listed in the first column representing the RRC configuration for the source network element and the second column representing the RRC configuration for the target network element) are identical and are therefore not included in the differential configuration (third column). Later, after a possible DRB update (i.e., deletion / removal of DRB2 and corresponding QoS flow 2 (Table 2)), only non-identical elements are included in the differential configuration again. In particular, since the newly created target differential configuration (after the DRB update) is the same as the initial differential configuration (before the DRB update), the source network element can be configured to skip sending the newly created differential configuration to the UE in order to reduce excessive radio signaling.

[0105] Before going into more technical details about the proposed mechanism / technique itself, it may be worthwhile to first introduce, from a high-level perspective, some possible system settings (architectures) to which the proposed mechanism / technique may be considered applicable. However, as can be understood and appreciated by those skilled in the art, Fig. 9A and Fig. 9B These system setups (architectures) shown are provided merely as some possible illustrative examples and should in no way be construed as limitations of any kind.

[0106] In particular, Fig. 9A A possible exemplary system setup for a CHO use case is schematically illustrated. Therein, a UE 910 is connected (as indicated by a double-dashed arrow) to a source gNB 920 (which has a service area indicated by a circle). On the other hand, under certain conditions, the UE may be configured with CHO towards a set of potential target gNBs (as exemplarily shown as target gNB 1 930 and target gNB 2 940), each with a respective service area indicated by a respective circle.

[0107] Similarly, Fig. 9B A possible exemplary system setup for a CP(A)C use case is schematically illustrated. Therein, a UE 910 is connected (as indicated by a double-dashed arrow) to a source MN 950 (which has a service area indicated by a larger outer circle). On the other hand, under certain conditions, the UE may be configured with CPC / CPA towards a set of potential target SNs (as exemplarily shown as target SN 1 960 and target SN 2 970), each with a corresponding service area indicated by a corresponding circle. Additionally, in some possible implementations, the UE may also be connected to a source SN 990 (which has a service area indicated by a smaller circle), for example, when operating in a dual connectivity setup, in addition to the connection to the source MN 950 (as shown in FIG. 1 ). Fig. 9B ).

[0108] These proposed mechanisms / techniques will now be described in more detail with reference to the accompanying drawings. It should be noted that, as described above, unless otherwise indicated, the same or similar reference numerals used in the drawings of the present disclosure may indicate the same or similar elements. Similarly, unless otherwise indicated, the same or similar messages (and the contents included therein) used in the drawings of the present disclosure may indicate the same or similar messages (and the contents therein), so that their repeated descriptions may be omitted for the sake of brevity.

[0109] first, Figure 5 An example of configuration update for CHO according to some example embodiments of the present disclosure is schematically shown.

[0110] Usually, in Figure 5 In the example of , it can be understood that for the case of CHO, the source network element (the source gNB in ​​this example) can be configured to store the initial delta configuration received with, for example, a CHO request ACK (or similar message). After a user plane configuration change (e.g., a PDU session is released or established, or a DRB to QoS flow mapping is updated, etc.), the source gNB can be configured to update the DRB configuration of the UE. Subsequently, the source gNB indicates this change to the target gNB(s) and receives the new delta configuration(s) from the target gNB(s) accordingly. The source gNB can then be configured to compare the new delta configuration(s) with the corresponding initial delta configuration(s) already stored by the source gNB. If the new delta configuration is the same as the initial delta configuration, the source gNB can be configured not to send the RRC reconfiguration message(s) to the UE. In other words, the source gNB can be configured to skip updating the conditional configuration(s) of the target cell(s) if it / they have not been changed.

[0111] More specifically, if Figure 5 As shown, in step S501, the source gNB sends a CHO request (or other similar suitable message) to (each of) the target gNBs (numbered #1 to #N). As can be understood and appreciated by those skilled in the art, even for ease of explanation, in Figure 5 While two target gNBs (numbered #1 and #N, respectively) are shown in the example, any other suitable number of target gNBs (even just one in some possible cases) may be possible depending on various implementations and / or requirements.

[0112] Subsequently, in steps S502 and S503, the target gNB may be configured to obtain (e.g., generate, determine, or by using any other suitable means) a corresponding (initial) delta for the RRC configuration of each target cell. As can be understood and appreciated by those skilled in the art, the delta configuration is generated based on the source cell configuration and the target cell configuration (see also the illustrations above with reference to Tables 1 and 2).

[0113] In steps S504 and S505, the target gNB may acknowledge the CHO request using, for example, a CHO request ACK along with the differential configuration, which is sent from the target gNB back to the source gNB.

[0114] In step S506, the source gNB may be configured to store (e.g., in a suitable memory, etc.) the differential configuration received from the target gNB in ​​steps S504 and S505.

[0115] Thereafter, in steps S507 and S508, an RRC reconfiguration with a differential configuration for CHO is sent from the source gNB to the UE (step S507), and in return, the UE sends an RRC reconfiguration completion back to the source gNB (step S508).

[0116] As illustrated in steps S509 and S510, the user plane configuration may be updated (eg, a PDU session is released or established, or a DRB to QoS flow mapping is updated, etc.), and the corresponding DRB configuration may also be updated.

[0117] As a result, in step S511, the source gNB sends a new CHO request set with the updated DRB configuration (or the like) to the corresponding target gNB.

[0118] Thus, the target gNB may accept or reject the change to the DRB configuration (or the like). In the event that the change is to be accepted, the target gNB may update the user RRC configuration in response to such updated user plane configuration (e.g., DRB configuration) and obtain (e.g., generate) a corresponding new delta configuration, as illustrated in steps S512 and S513.

[0119] In steps S514 and S515, the target gNB acknowledges the CHO request with a corresponding CHO request ACK (or the like) and the new delta configuration, which is sent back to the source gNB.

[0120] In which, as exemplarily shown in step S516, the source gNB can be configured to compare the received new differential configuration set with the stored initial differential configuration.

[0121] If a difference is detected in step S516 (e.g., for any of the corresponding differential configuration pairs before and after the user plane update), the corresponding differential configuration is sent by the source gNB to the UE to update the RRC configuration within the CHO configuration in step S517. Accordingly, the UE may confirm such reconfiguration, as illustrated in step S518. It is worth noting that, depending on various implementations and / or requirements, the source gNB may be configured to prepare and transmit a separate RRC reconfiguration message (for each detected difference in the differential configuration) or one (concatenated) RRC reconfiguration message (e.g., with different differential configurations for different target cells as different IEs within a single RRC reconfiguration message).

[0122] On the other hand, if the corresponding delta configurations are found to be the same in step S516, the reconfiguration message(s) may be skipped.

[0123] Secondly, Figure 6 An example of configuration update for CPC / CPA according to some example embodiments of the present disclosure is schematically shown. As described above, unless otherwise specified, the same or similar reference numerals or messages (and the contents included therein) used in the drawings of the present disclosure may indicate the same or similar element messages (and the corresponding contents therein), so that repeated descriptions thereof may be omitted for the sake of brevity.

[0124] Generally speaking, Figure 6 In the example, it can be understood that for the case of CP(A)C, the source MN (similar to the above Figure 5 The source gNB described in relation to CHO in may be configured to store an initial differential configuration received with, for example, an SN add request ACK (or similar message). After a user plane configuration change (e.g., a PDU session is released or established, or a DRB to QoS flow mapping is updated, etc.), the source MN may be configured to update the DRB configuration of the UE. Subsequently, the source MN indicates the change to the target SN and receives a new differential configuration from the target SN. The source MN may then be configured to compare the new differential configuration with the initial differential configuration already stored by the source MN. If the new differential configuration is the same as the initial differential configuration, the source MN may be configured not to send an RRC reconfiguration message (or the like) to the UE. In other words, the source MN may be configured to skip the update of the conditional configuration of the target cell if it / they have not been changed.

[0125] It is worth noting that, as can be seen from the figure, Figure 6 The example embodiment shown is more or less similar to Figure 5 The example embodiment shown, except for the network elements involved (i.e., Figure 5 Source / target gNB comparison in CHO case Figure 6 In addition to the source MN / target SN in the case of CP(A)C and the corresponding messaging / signaling exchanged between the respective network elements.

[0126] More specifically, if Figure 6 As shown, in step S601, the source MN sends an SN add request (or other similar appropriate message) to (each of) the target SNs (numbered #1 to #N). As can be understood and appreciated by those skilled in the art, even for the sake of convenience, in Figure 6 While two target SNs (numbered #1 and #N, respectively) are shown in the example, any other suitable number of target SNs (even only one in some possible cases) is possible according to various implementations and / or requirements.

[0127] Subsequently, in steps S602 and S603, the target SN may be configured to obtain (e.g., generate, determine, or by using any other suitable means) a corresponding (initial) delta of the RRC configuration for each target cell. As those skilled in the art can understand and appreciate, the delta configuration is generated based on the source cell configuration and the target cell configuration (see also the illustrations with reference to Tables 1 and 2 above).

[0128] In steps S604 and S605, the target SN may acknowledge the SN add request using, for example, a SN add request ACK and a delta configuration, which is sent from the target SN back to the source MN.

[0129] In step S606, the source MN may be configured to store (eg, in a suitable memory, etc.) the delta configuration received from the target SN in steps S604 and S605.

[0130] Thereafter, in steps S607 and S608, an RRC reconfiguration with a differential configuration is sent from the source MN to the UE (step S507), and in return, the UE sends back an RRC reconfiguration completion to the source MN (step S508).

[0131] As illustrated in steps S609 and S610, the user plane configuration may be updated (eg, a PDU session is released or established, or a DRB to QoS flow mapping is updated, etc.), and the corresponding DRB configuration may also be updated.

[0132] As a result, in step S611, the source MN sends a new SN addition request set with an updated DRB configuration (or the like) to the corresponding target SN.

[0133] Thus, the target SN may accept or reject the change to the DRB configuration (or the like). In the case where the change is to be accepted, the target SN may update the user RRC configuration and obtain (e.g., generate) a corresponding new delta configuration in response to such updated user plane configuration (e.g., DRB configuration), as illustrated in steps S612 and S613.

[0134] In steps S614 and S615, the target SN acknowledges the SN Add Request with a corresponding SN Add Request ACK (or the like) and the new delta configuration (which is again sent back to the source gNB).

[0135] As exemplarily shown in step S616, the source MN may be configured to compare the received new differential configuration set with the stored initial differential configuration.

[0136] If a difference is detected in step S616 (e.g., for any one of the corresponding differential configuration pairs before and after the user plane update), the source gNB sends the corresponding differential configuration to the UE to update the RRC configuration within the CP(A)C configuration in step S617. Accordingly, the UE may confirm such reconfiguration, as illustrated in step S618. It is worth noting that, depending on various implementations and / or requirements, the source MN may be configured to prepare and transmit a separate RRC reconfiguration message (for each detected difference in the differential configuration) or one (concatenated) RRC reconfiguration message (e.g., with different differential configurations for different target cells as different IEs within a single RRC reconfiguration message).

[0137] On the other hand, if the corresponding delta configurations are found to be the same in step S616, the reconfiguration message(s) may be skipped.

[0138] It is worth noting that, as may also be understood and appreciated by those skilled in the art, there may generally be some differences in the RRC (re)configuration in the case of CHO and CP(A)C procedures. Specifically, in the case of CHO, information about the DRB configuration may generally be included in the RRCReconfiguration, which is within the handover command, which itself is in the target NG-RAN node to source NG-RAN node transparent container of the handover request confirmation (ACK). On the other hand, in the case of CPC, information about the DRB configuration may generally be included in the CG-Config, which is in the S-NG-RAN node to M-NG-RAN node container of the S-Node Modification Request Confirmation (ACK).

[0139] also, Figure 7Another example of configuration update for CHO according to some example embodiments of the present disclosure is schematically shown. As described above, unless otherwise specified, the same or similar reference numerals or messages (and the contents included therein) used in the drawings of the present disclosure may indicate the same or similar element messages (and the corresponding contents therein), so that their repeated description may be omitted for the sake of brevity.

[0140] Generally speaking, Figure 7 In the example embodiment of Figure 5 The source gNB (illustratively shown) is configured to store an initial delta configuration of candidate cells obtained (e.g., created) by the target gNB after receiving an initial CHO request (or similar message). After a user plane configuration change, such as a PDU session being released or established, or a DRB to QoS flow mapping being updated, etc., the source network element may update the DRB configuration of the UE. The source gNB then indicates the change to the target gNB. Based on the modification, the target gNB generates a new delta configuration and sends it to the target gNB (not to the target gNB as described above). Figure 5The source gNB (illustratively shown) compares these configurations with the initial differential configurations (which have been stored by the target gNB). If these configurations are the same, the target gNB does not send a new differential configuration, but can indicate the same differential configuration to the source gNB in ​​the CHO request ACK. It is worth noting that, as can be understood and appreciated by a person skilled in the art, such indication that the differential configuration is the same (or in other words, the differential configuration has not been changed / updated) can be achieved by using any suitable (explicit) means, such as (but not to be understood as any kind of limitation) (Boolean) flags, (binary or enumerated) values, bitmaps for each PCell (which can itself be included in flags, etc.), etc. In some possible (non-limiting) examples, information indicating that the differential configurations before and after the user plane configuration are the same can also be implicitly conveyed, for example, by not sending (omitting) a CHO request ACK (or the like) to the source gNB. In other words, the omission or absence of a suitable message (or part thereof, such as a suitable IE) can be used to implicitly indicate the same differential configuration. In some possible implementations (e.g., only one RRC reconfiguration is exchanged between the source gNB and the UE regardless of the number of target gNBs), if all target gNBs indicate the same differential configuration, the source gNB may be configured to skip the process of sending the RRC reconfiguration and receiving the RRC reconfiguration complete message from the UE. Accordingly, in the event that a subset of the prepared target gNBs indicate different differential configurations, the source gNB will send RRC reconfigurations only for those that do not indicate the same differential configuration. On the other hand, in some other possible implementations (e.g., corresponding RRC reconfigurations are to be exchanged between the source gNB and the UE for each target gNB), the source gNB may be configured to skip the process of sending the RRC reconfiguration and receiving the RRC reconfiguration complete message from the UE only for those that indicate the same differential configuration, while still performing the usual RRC reconfiguration process for other target gNBs that indicate different differential configurations.

[0141] Reference now Figure 7 As shown in step S701, the source gNB sends a CHO request (or other similar appropriate message) to (each of) the target gNBs (numbered #1 to #N). As can be understood and appreciated by those skilled in the art, even for ease of explanation, in Figure 7 While two target gNBs (numbered #1 and #N, respectively) are shown in the example, any other suitable number of target gNBs (even just one in some possible cases) may be possible depending on various implementations and / or requirements.

[0142] exist Figure 7 In this example (with Figure 5 ), instead of Figure 5The source gNB is configured to store the (initial) delta configuration, this time it is the target gNB that is configured to generate and subsequently store the delta of the RRC configuration for the target cell. Similar to the above, the delta configuration is generated based on the source cell configuration and the target cell configuration (as exemplarily shown in steps S702 and S703).

[0143] In steps S704 and S705, the target gNB may acknowledge the CHO request using, for example, a CHO request ACK along with a differential configuration, which is sent from the target gNB back to the source gNB.

[0144] Subsequently, in steps S706 and S707, an RRC reconfiguration with a differential configuration for CHO is sent from the source gNB to the UE (step S706), and in return, the UE sends an RRC reconfiguration complete back to the source gNB (step S707).

[0145] As illustrated in steps S708 and S709, the user plane configuration may be updated (eg, a PDU session is released or established, or a DRB to QoS flow mapping is updated, etc.), and the corresponding DRB configuration may also be updated.

[0146] As a result, in step S710, the source gNB sends a new CHO request set with the updated DRB configuration (or the like) to the corresponding target gNB.

[0147] Thus, the target gNB may accept or reject the change to the DRB configuration (or the like). In the event that the change is to be accepted, the target gNB may update the user RRC configuration and obtain (e.g., generate) a corresponding new delta configuration in response to such updated user plane configuration (e.g., DRB configuration). Figure 7 In this example, as illustrated in steps S711 and S712, the target gNB is now configured to compare the newly generated / created delta configuration with the delta configuration already stored in the target gNB (as illustrated in steps S702 and S703), rather than Figure 5 The source gNB is shown in the example.

[0148] As exemplarily shown in steps S713 and S714, if it is determined that the new differential configuration is different from the initial differential configuration (as compared in steps S711 and S712), the target gNB confirms the CHO request with a corresponding CHO request ACK (or the like) and the new differential configuration (which is sent back to the source gNB).

[0149] On the other hand, as exemplarily shown in steps S715 and S716, if it is determined that the new differential configuration is the same as the initial differential configuration (as compared in steps S711 and S712), the target gNB may be configured to communicate this to the source gNB by using any suitable means as described above. For example, as an illustrative example (but not as any kind of limitation), the target gNB may be configured to send (only) a corresponding flag in the CHO request ACK (or the like), which indicates that the configuration before and after the update are the same, rather than a complete (full or differential) configuration. As can be understood and appreciated by a person skilled in the art, such a flag may be implemented by using any suitable means, such as (reusing) old parameters / IEs or (introducing) new parameters / IEs. Of course, as described above, any other suitable implementation besides a flag may be adopted, whether explicit or implicit.

[0150] Therefore, if a new configuration is received with a CHO request ACK, the source gNB sends the configuration to the UE with an RRC reconfiguration (step S717), and receives a corresponding RRC reconfiguration completion from the UE (step S718).

[0151] On the other hand, Figure 7 In an illustrative example of (where a possible flag is used to convey an indication that the configuration before and after the update is the same), if there is a flag in the received CHO request ACK indicating that the differential configuration is the same, the source gNB can be configured to not send (skip) the configuration to the UE.

[0152] at last, Figure 8 Another example of configuration update for CPC / CPA according to some example embodiments of the present disclosure is schematically shown. As described above, unless otherwise specified, the same or similar reference numerals or messages (and the contents included therein) used in the drawings of the present disclosure may indicate the same or similar element messages (and the corresponding contents therein), so that repeated descriptions thereof may be omitted for the sake of brevity.

[0153] Generally speaking, Figure 8 In the example of CP(A)C, it can be understood that for the case of CP(A)C, (multiple) target SNs (similar to the above Figure 7The target gNB described in relation to the CHO case in ) may be configured to store the initial delta configuration received with, for example, the SN Add Request ACK (or similar message). After a user plane configuration change (e.g., a PDU session is released or established, or a DRB to QoS flow mapping is updated, etc.), the source MN may be configured to update the DRB configuration of the UE. Subsequently, the source MN indicates the change to the target SN. Based on the modification, the target SN may be configured to generate new delta configurations and compare these configurations with the already stored initial delta configurations. If these configurations are the same, the target SN may be configured to indicate the same delta configuration, rather than sending the configuration to the source MN, for example, by a flag in the SN Modify Request ACK (or the like). As described above, such indication that the delta configurations are the same (or in other words, that the delta configuration has not been changed / updated) may be achieved using any suitable (explicit) means, such as (but not to be construed as any kind of limitation) a (Boolean) flag, a (binary or enumerated) value, a bitmap for each PSCell (which itself may be contained in a flag, etc.), etc. In some possible (non-limiting) examples, information indicating that the differential configuration before and after the user plane configuration is the same can also be implicitly conveyed, for example, by not sending (omitting) an SN modification request ACK to the source MN, etc. In other words, the omission or absence of a suitable message (or a portion thereof, such as a suitable IE) can be used to implicitly indicate the same differential configuration. In some possible implementations (for example, only one RRC reconfiguration is exchanged between the source MN and the UE regardless of the number of target SNs), if all target SNs indicate the same differential configuration, the source MN can be configured to skip the process of sending the RRC reconfiguration and receiving the RRC reconfiguration completion message from the UE. Accordingly, in the case where a subset of the prepared target SNs indicates different differential configurations, the source MN can send an RRC reconfiguration only for those that do not indicate the same differential configuration. On the other hand, in some other possible implementations (for example, exchanging corresponding RRC reconfigurations between the source MN and the UE for each target SN), the source MN can be configured to skip the process of sending RRC reconfigurations and receiving RRC reconfiguration completion messages from the UE only for those indicating the same differential configuration, while still performing the usual RRC reconfiguration process for other target SNs indicating different differential configurations.

[0154] It should also be noted that similar to Figure 5 and Figure 6 The example embodiment shown, Figure 8 The example embodiment shown is more or less similar to Figure 7 The example embodiments shown, except for those involving network elements (i.e., Figure 7 Source / target gNB comparison in CHO case Figure 8The source MN / target SN in the case of CP(A)C and the corresponding messaging / signaling exchanged between the respective network elements.

[0155] More specifically, if Figure 8 As shown in the illustrative (non-limiting) example of FIG. 8 , in step S801, the source MN sends an SN add request (or other similar suitable message) to (each of) the target SNs (numbered #1 to #N). As can be understood and appreciated by those skilled in the art, even for ease of explanation, in Figure 6 While two target SNs (numbered #1 and #N, respectively) are shown in the example, any other suitable number of target SNs (even only one in some possible cases) is possible according to various implementations and / or requirements.

[0156] exist Figure 8 In this example (with Figure 6 ), instead of the source MN being configured to store Figure 5 The (initial) delta configuration shown in the example of , this time the target gNB is configured to generate and subsequently store a delta of the RRC configuration for the target cell. Similar to the above, the delta configuration is generated based on the source cell configuration and the target cell configuration (as exemplarily shown in steps S802 and S803).

[0157] In steps S804 and S805, the target SN may acknowledge the SN add request using, for example, a SN add request ACK and a delta configuration, which is sent from the target SN back to the source MN.

[0158] Then in steps S806 and S807, an RRC reconfiguration with a differential configuration for CP(A)C is sent from the source MN to the UE (step S806), and in return, the UE sends back an RRC reconfiguration complete to the source MN (step S807).

[0159] As illustrated in steps S808 and S809, the user plane configuration may be updated (eg, a PDU session is released or established, or a DRB to QoS flow mapping is updated, etc.), and the corresponding DRB configuration may also be updated.

[0160] As a result, in step S810, the source MN sends a new SN addition request set with an updated DRB configuration (or the like) to the corresponding target SN.

[0161] Thus, the target SN may accept or reject the change to the DRB configuration (or the like). In the event that the change is to be accepted, the target SN may update the UE RRC configuration and obtain (e.g., generate) a corresponding new delta configuration in response to such updated user plane configuration (e.g., DRB configuration). Figure 8 In this example, as illustrated in steps S811 and S812, the target SN is now configured to compare the newly generated / created delta configuration with the delta configuration already stored in the target SN (as illustrated in steps S802 and S803), rather than Figure 6 The source MN is shown in the example.

[0162] As exemplarily shown in steps S813 and S814, if it is determined that the new differential configuration is different from the initial differential configuration (as compared in steps S811 and S812), the target SN confirms the SN add request using a corresponding SN add request ACK (or the like) containing the new differential configuration.

[0163] On the other hand, as exemplarily shown in steps S815 and S816, if it is determined that the new differential configuration is the same as the initial differential configuration (as compared in steps S811 and S812), the target SN may be configured to transmit it to the source MN by using any suitable means as described above. For example, as an illustrative example (but not as any kind of limitation), the target SN may be configured to send (only) a corresponding flag in the SN Add Request ACK message (or the like), which indicates that the configuration before and after the update is the same, rather than a complete (complete or differential) configuration. As can be understood and appreciated by those skilled in the art, such a flag can be implemented by using any suitable means, such as (reusing) old parameters / IEs or (introducing) new parameters / IEs. Of course, as described above, any other suitable implementation besides the flag may be adopted, whether it is an explicit indication or an implicit indication.

[0164] Therefore, if a new configuration is received with the SN Add Request ACK, the source MN sends the configuration to the UE with RRC Reconfiguration (step S817), and receives a corresponding RRC Reconfiguration Complete from the UE (step S818).

[0165] On the other hand, Figure 8 In an illustrative example (where a possible flag is used to convey an indication that the configuration before and after the update is the same), if there is a flag in the received SN add request ACK indicating that the differential configuration is the same, the source MN can be configured to not send (skip) any configuration to the UE.

[0166] It may be worth pointing out that, as can be understood and appreciated by those skilled in the art, the example embodiments shown above with reference to the accompanying drawings may generally be considered to relate to mobility procedures in (when the UE is in) an RRC connected state. In other words, it may generally be understood that the UE has been connected (RRC connected) to a source / serving cell, for example, controlled by a source / serving network element / node; and the UE has been configured with an (initial) RRC configuration. In addition, the terms "initial differential (RRC) configuration" (obtained during the mobility preparation phase) and "new / updated differential (RRC) configuration" (obtained during the mobility assessment phase) may have been used in the above-described example embodiments. However, in some possible cases, they may be simply referred to as the first and second (or any other suitable numbering, or even any other suitable different naming) differential (RRC) configurations, respectively. In view of this, in a broad sense, as those skilled in the art may also understand and appreciate, the expression "initial" or "first" (or the like) may generally be regarded as referring to the current (currently applied) RRC configuration configured at the UE; while the expression "new / updated" or "second" (or the like) may generally be regarded as referring to the new / most recently generated RRC configuration to be applied at the UE. Therefore, it is also conceivable that, in some possible cases, the first delta (RRC) configuration does not necessarily always have to be used to refer to the delta configuration obtained (e.g., generated) during the mobility preparation phase, but both the first and second delta (RRC) configurations may be obtained during the mobility assessment phase (or the like).

[0167] In summary, it is worth noting that the mechanism / technique as proposed in the present disclosure generally avoids unnecessary reconfiguration of conditional configurations when the new configuration is the same as the old configuration, thereby also reducing signaling overhead on the radio interface. In addition, it should be noted that the mechanism / technique proposed in the present disclosure also does not require complex coordination mechanisms between the source network element and the target network element, thereby further improving the efficiency and flexibility of the entire system.

[0168] For the sake of completeness, it should be noted that in any of the example embodiments described above with reference to the drawings of the present disclosure, where a network element (e.g., a target gNB or a target SN) is associated with more than one cell, a differential configuration may be obtained on a per-cell basis, as may be understood and appreciated by those skilled in the art.

[0169] Finally, it should be noted that although in the above-described example embodiments (with reference to the accompanying drawings), the messages transmitted / exchanged between network components / elements may appear to have specific / unambiguous names, depending on various implementations (e.g., underlining techniques), these messages may have different names and / or be transmitted / exchanged in different forms / formats, as can be understood and appreciated by those skilled in the art.

[0170] According to some example embodiments, corresponding methods suitable for being performed by the apparatus (network elements / components) described above, such as UE, source network element and target network element (e.g., gNB, MN, SN, etc.) are also provided.

[0171] It should also be noted that the above-mentioned device (or system) features correspond to corresponding method features, however, for reasons of brevity, these method features may not be explicitly described. The disclosure of this document is considered to extend to such method features as well. In particular, the disclosure is understood to relate to methods of operating the above-mentioned devices, and / or to providing and / or arranging corresponding elements of these devices.

[0172] In addition, according to some other example embodiments, a corresponding device (for example, implementing the UE, source / target gNB, MN, SN, etc. as described above) is also provided, which includes at least one processing circuit and at least one memory for storing instructions to be executed by the processing circuit, wherein the at least one memory and the instructions are configured to, together with the at least one processing circuit, enable the corresponding device to at least perform the corresponding steps as described above.

[0173] Fig.10 An illustrative (non-limiting) example of such an apparatus 1000 is schematically shown in . The apparatus 1000 may be implemented as any suitable network node / component / element for a communication system, for example, to couple to and / or control a station of an access system, such as a RAN node, such as a base station, eNB or gNB, a relay node or a core network node, such as an MME or S-GW or P-GW, or a core network function, such as an AMF / SMF, a server or host, a MN or SN, or a UE in some possible implementations. According to various implementations, the methods described in the present disclosure may be implemented in a single device or across more than one device. The device may be integrated with or external to a node or module of a core network, RAN, etc. In particular, the apparatus 1000 may be arranged to provide control of communications in a service area of ​​the system. The control device 1000 may include at least one memory 1001, at least one data processing unit (or circuit) 1002, 1003, and an input / output interface 1004. Via interface 1004, apparatus 1000 may be coupled to any other suitable components of apparatus 1000 (eg, a receiver and / or transmitter), or to any other suitable other apparatus. In some possible examples, the receiver and / or transmitter may be implemented as a radio front end or a remote radio head.

[0174] However, in some other example embodiments, a corresponding apparatus (e.g., implementing the UE, source / target gNB, MN, SN, etc. as described above) is provided, which includes corresponding components configured to at least perform the corresponding steps as described above.

[0175] It should be noted that the examples of the embodiments of the present disclosure are applicable to a variety of different network configurations. In other words, the examples shown in the above-mentioned figures (which serve as the basis for the above-mentioned examples) are merely illustrative and do not limit the present disclosure in any way. That is, based on the defined principles, additional existing and proposed new functions available in the corresponding operating environment can be used in conjunction with the examples of the embodiments of the present disclosure.

[0176] It should also be noted that the disclosed example embodiments can be implemented in many ways using hardware and / or software configurations. For example, the disclosed embodiments can be implemented using dedicated hardware and / or hardware associated with software executable thereon. The components and / or elements in the accompanying drawings are only examples and do not limit the scope of use or functionality of any hardware, software in combination with hardware, firmware, embedded logic components, or a combination of two or more such components that implement a particular embodiment of the present disclosure.

[0177] It should also be noted that the description and the accompanying drawings illustrate only the principles of the present disclosure. Those skilled in the art will be able to implement various arrangements that, although not explicitly described or illustrated herein, embody the principles of the present disclosure and are included in its spirit and scope. In addition, all examples and embodiments outlined in the present disclosure are primarily intended to be used explicitly only for explanatory purposes to help the reader understand the principles of the proposed method. In addition, all statements of the principles, aspects, and embodiments of the present disclosure and their specific examples provided herein are intended to cover their equivalents.

Claims

1. A method for supporting a conditional mobility procedure, the conditional mobility procedure involving a source network element and at least one target network element, the source network element serving a user equipment UE, the method comprising: obtaining a first differential radio resource control (RRC) configuration, the first differential RRC configuration indicating a difference between an RRC configuration of the source network element and an RRC configuration of the target network element; storing the first differential RRC configuration; obtaining a second differential RRC configuration, the second differential RRC configuration indicating a difference between the RRC configuration of the source network element and the RRC configuration of the target network element after a user plane configuration of the UE has been updated; comparing the obtained second differential RRC configuration with the stored first differential RRC configuration to determine whether the first differential RRC configuration is the same as the second differential RRC configuration; Based on determining that the first differential RRC configuration is different from the second differential RRC configuration: transmitting an RRC reconfiguration message to the UE; and Based on determining that the first differential RRC configuration is the same as the second differential RRC configuration: Skipping the transmission of the RRC reconfiguration message to the UE.

2. The method of claim 1 , wherein the first differential RRC configuration is stored by the source network element; and wherein the first differential RRC configuration and the second differential RRC configuration are compared by the source network element.

3. The method according to claim 1 or 2, wherein the obtaining of the first RRC configuration comprises: transmitting, by the source network element to the target network element, a first request message indicating the conditional mobility procedure; as well as The first differential RRC configuration is received by the source network element from the target network element.

4. The method according to any one of the preceding claims, wherein the obtaining of the second RRC configuration comprises: transmitting, by the source network element to the target network element, a second request message indicating the update of the user plane configuration of the UE; as well as The second delta RRC configuration is received by the source network element from the target network element.

5. A method according to any one of the preceding claims, wherein: Based on determining that the first differential RRC configuration is different from the second differential RRC configuration: transmitting, by the source network element to the UE, the RRC reconfiguration message for conveying the RRC configuration for the conditional mobility procedure of the target network element regarding the updated user plane configuration; and Based on determining that the first differential RRC configuration is the same as the second differential RRC configuration: The transmission of the RRC reconfiguration message to the UE is skipped by the source network element.

6. The method of claim 1, wherein the first differential RRC configuration is stored by the target network element; and wherein the first differential RRC configuration and the second differential RRC configuration are compared by the target network element.

7. The method according to claim 1 or 6, wherein the obtaining of the first RRC configuration comprises: receiving, by the target network element from the source network element, a first request message indicating the conditional mobility procedure; as well as The first differential RRC configuration is generated by the target network element.

8. The method according to any one of claims 1 and 6 to 7, wherein the obtaining of the second RRC configuration comprises: receiving, by the target network element from the source network element, a second request message indicating the update of the user plane configuration of the UE; as well as The second delta RRC configuration is generated by the target network element based on the updated user plane configuration.

9. The method according to any one of claims 1 and 6 to 8, wherein: Based on determining that the first differential RRC configuration is different from the second differential RRC configuration: transmitting, by the target network element to the source network element, the second differential RRC configuration; and transmitting, by the source network element to the UE, an RRC reconfiguration message for conveying the RRC configuration for the conditional mobility procedure of the target network element regarding the updated user plane configuration; and Based on determining that the first differential RRC configuration is the same as the second differential RRC configuration: transmitting, by the target network element, information indicating that the first differential RRC configuration and the second differential RRC configuration are the same for the source network element, and The transmitting of the RRC reconfiguration message to the UE is skipped by the source network element based on the information indicating that the first differential RRC configuration is the same as the second differential RRC configuration.

10. The method of claim 9, wherein the first differential RRC configuration being the same as the second differential RRC configuration is indicated by at least one of: a flag, a value, a bitmap, or an absence of the transmission of the second differential RRC configuration or a portion thereof.

11. The method according to any of the preceding claims, wherein the conditional mobility procedure relates to a conditional handover (CHO) procedure.

12. The method of claim 11, wherein the source network element and the target network element are each a gNB.

13. The method according to any one of claims 1 to 10, wherein the conditional mobility procedure involves a conditional PSCell change (CPC) procedure or a conditional PSCell addition (CPA) procedure.

14. The method according to claim 13, wherein the source network element is a master node MN and the target network element is a slave node SN.

15. A communication system comprising a source network element, at least one target network and a user equipment UE served by the source network element, wherein the communication system is configured to perform the method as claimed in any one of the preceding claims.

16. A source network element configured to support a conditional mobility procedure involving at least one target network element and a user equipment (UE) served by the source network element, the source network element comprising: at least one processor; as well as at least one memory storing instructions, which, when executed by the at least one processor, cause the source network element to at least: obtaining a first differential radio resource control (RRC) configuration, the first differential RRC configuration indicating a difference between an RRC configuration of the source network element and an RRC configuration of the target network element; storing the first differential RRC configuration; obtaining a second differential RRC configuration, the second differential RRC configuration indicating a difference between the RRC configuration of the source network element and the RRC configuration of the target network element after a user plane configuration of the UE has been updated; comparing the obtained second differential RRC configuration with the stored first differential RRC configuration to determine whether the first differential RRC configuration is the same as the second differential RRC configuration; Based on determining that the first differential RRC configuration is different from the second differential RRC configuration: transmitting an RRC reconfiguration message to the UE; and Based on determining that the first differential RRC configuration is the same as the second differential RRC configuration: Skipping the transmission of the RRC reconfiguration message to the UE.

17. The source network element of claim 16, wherein the source network element obtains the first differential RRC configuration by: receiving the first differential RRC configuration from the target network element in response to a first request message indicating the conditional mobility procedure being sent to the target network element; and The source network element obtains the second differential RRC configuration by: In response to a second request message indicating the conditional mobility procedure being sent to the target network element, the second differential RRC configuration is received from the target network element.

18. A source network element according to claim 16 or 17, wherein When the conditional mobility procedure relates to a conditional handover (CHO) procedure, the source network element is a gNB, and the first conditional mobility procedure request and the second conditional mobility procedure request are conditional handover requests; or When the conditional mobility procedure involves a conditional PSCell change CPC procedure or a conditional PSCell addition CPA procedure, the source network element is a master node MN, and the first conditional mobility procedure request and the second conditional mobility procedure request are SN addition requests.

19. A target network element, configured to support a conditional mobility procedure, the conditional mobility procedure involving a source network element and the target network element, the source network element serving a user equipment UE, the target network element comprising: at least one processor; as well as at least one memory storing instructions, which, when executed by the at least one processor, cause the target network element to at least: obtaining a first differential radio resource control (RRC) configuration, the first differential RRC configuration indicating a difference between an RRC configuration of the source network element and an RRC configuration of the target network element; storing the first differential RRC configuration; obtaining a second differential RRC configuration, the second differential RRC configuration indicating a difference between the RRC configuration of the source network element and the RRC configuration of the target network element after a user plane configuration of the UE has been updated; comparing the obtained second differential RRC configuration with the stored first differential RRC configuration to determine whether the first differential RRC configuration is the same as the second differential RRC configuration; Based on determining that the first differential RRC configuration is different from the second differential RRC configuration: transmitting the second delta RRC configuration to the source network element for enabling the source network element to transmit an RRC reconfiguration message to the UE; and Based on determining that the first differential RRC configuration is the same as the second differential RRC configuration: Information indicating that the first differential RRC configuration and the second differential RRC configuration are the same for the source network element is transmitted, so that transmission of the RRC reconfiguration message from the source network element to the UE can be skipped.

20. The target network element according to claim 19, wherein the target network element obtains the first differential RRC configuration by: generating, by the target network element, the first differential RRC configuration based on a received first request message indicating the conditional mobility procedure; and The target network element obtains the second differential RRC configuration by: The second delta RRC configuration is generated by the target network element based on a received second request message indicating the conditional mobility procedure.

21. The target network element according to claim 19 or 20, wherein When the conditional mobility procedure relates to a conditional handover (CHO) procedure, the target network element is a gNB, and the first conditional mobility procedure request and the second conditional mobility procedure request are conditional handover requests; or When the conditional mobility procedure involves a conditional PSCell change CPC procedure or a conditional PSCell addition CPA procedure, the target network element is a secondary node SN, and the first conditional mobility procedure request and the second conditional mobility procedure request are SN addition requests.

22. A source network element configured to support a conditional mobility procedure involving at least one target network element and a user equipment (UE) served by the source network element, the source network element comprising: at least one processor; as well as at least one memory storing instructions, which, when executed by the at least one processor, cause the source network element to at least: transmitting a first request message indicating the conditional mobility procedure to the target network element; receiving, in response to the first conditional mobility procedure request, a first differential RRC configuration from the target network element; transmitting, based on the received first differential RRC configuration, a first RRC reconfiguration message to the UE, conveying the RRC configuration used by the target network element for the conditional mobility procedure; sending, in response to updating a user plane configuration of the UE, a second request message indicating the conditional mobility procedure to the target network element; When a second delta RRC configuration is received from the target network element in response to the second conditional mobility procedure request: transmitting a second RRC reconfiguration message to the UE; and When receiving, in response to the second conditional mobility request, information from the target network element indicating that the differential RRC configuration has not changed: Skipping the transmission of the second RRC reconfiguration message to the UE.

23. A computer program comprising instructions for causing an apparatus to perform the method according to any one of claims 1 to 14.

24. A memory storing computer-readable instructions for causing an apparatus to execute the method according to any one of claims 1 to 14.

Images