Conditional handover with target secondary node

Abstract

A target secondary node receives from a second target master node a secondary-node addition request message for preparing the target secondary node for a conditional handover (CHO) of a user equipment (UE) by establishing a user equipment context in association with the second target master node. The target secondary node determines that the target secondary node is already prepared for the CHO of the UE by identifying that the UE context exists in association with a first target master node. And, the target secondary node, transmits to at least one of the first and secondary target master node information indicating that the target secondary node is prepared for the CHO for the UE for more than one target master node. Also disclosed is a second target master node receiving a handover request acknowledgment comprising information regarding the preparation of a target secondary node for a CHO of a UE. Determining that the target secondary node is prepared for CHO of the UE for more than one target master node. And, transmitting to the first and second target master nodes information indicating that the target secondary node is prepared for CHO of the UE for more than one target master node.

Description

TECHNICAL FIELD This disclosure generally refers to mobile or wireless communication technology and systems. Various example embodiments relate to measures / mechanisms (including, e.g. methods, apparatuses and computer program products) for enabling (or otherwise facilitating or realizing) conditional handover with target secondary node. BACKGROUND Examples of mobile or wireless communication technology and systems may include the Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), Long Term Evolution (LTE) Evolved UTRAN (E-UTRAN), LTE-Advanced (LTE-A), MulteFire, LTE-A Pro, fifth generation (5G) radio access technology or new radio (NR) access technology and / or sixth generation (6G) radio access technology. At least fifth generation (5G) wireless systems, but potentially also sixth generation (6G) wireless systems, refer to the next generation (NG) of radio systems and network architecture. 5G and 6G network technology is based on new radio (NR) technology, but the 5G / 6G (or NG) network can also build on E-UTRAN radio. It is estimated that NR may provide bitrates on the order of 10-20 Gbit / s or higher and may support at least enhanced mobile broadband (eMBB) and ultra-reliable low-latency communication (URLLC) as well as massive machine-type communication (mMTC) services. NR is expected to deliver extreme broadband and ultra-robust, low-latency connectivity and massive networking to support the Internet of Things (loT). LIST OF ACRONYMS AND ABBREVIATIONS 3 GPP 5G 6G AMF cnn JL JLv^^ CP AC DC HO 3rd Generation Partnership Project Fifth Generation Sixth Generation Access and Mobility Management Function Conditional Handover Conditional PSCell Addition - Change Dual Connectivity Handover MCG Master Cell Group MN Master Node MR-DC Multi-Radio Dual Connectivity N3IWF Non-3GPP InterWorking Function NEF Network Exposure Function NFV(I) Network Function Virtualization (Infrastructure) NR New Radio PCell Primary Cell PSCell Primary Secondary Cell QoS Quality of Service PT O KJLV Radio Link Control SCG Secondary Cell Group SDN Software Defined Networking SN Secondary Node TEID Tunnel Endpoint Identifier TN GF Trusted Non-3GPP Gateway Function UE User Equipment UPF User Plane Function W-AGF Wireless Access Gateway Function BRIEF DESCRIPTION Various example embodiments address at least part of issues described herein or otherwise recognized by a person skilled in the art in view of this disclosure. Various example embodiments are set out in the claims. Some of the various example embodiments are described with respect to certain aspects. These aspects are not intended to indicate key or essential features of the various example embodiments, nor are they intended to be used to limit the scope of thereof. Other features, aspects, and elements will be recognized by a person skilled in the art in view of this disclosure. According to an example aspect, there is provided an apparatus which is adapted, configured and / or operable to receive, by a target secondary node from a second target master node, a secondary-node addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with the second target master node, determine, at the target secondary node, that the target secondary node is already prepared for the conditional handover of the user equipment by identifying that the user equipment context exists in association with a first target master node, and transmit, from the target secondary node to at least one of the first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. Further potential functionalities or operations of the apparatus are described below. The apparatus may be constructed, embodied or realized in various ways. For example, the apparatus may comprise at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform or carry out the respective functionalities or operations, the apparatus may comprise one or more means for performing or carrying out the respective functionalities or operations, the apparatus may comprise one or more circuitry for performing or carrying out the respective functionalities or operations, or the like. According to an example aspect, there is provided a method, comprising: receiving (e.g. by a target secondary node from a second target master node) a secondary-node addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with the second target master node, determining (e.g. at the target secondary node) that the target secondary node is already prepared for the conditional handover of the user equipment by identifying that the user equipment context exists in association with a first target master node, and transmitting (e.g. from the target secondary node to at least one of the first target master node and the second target master node) information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. Further potential steps or operations of the method are described below. According to an example aspect, there is provided an apparatus which is adapted, configured and / or operable to transmit, from a target master node to a target secondary node, a secondary-node addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with the target master node, receive, by the target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node, and determine, at the target master node, based on said information, that the user equipment context is to be kept when the target secondary node is to be released from the preparation for the conditional handover of the user equipment for the target master node. Further potential functionalities or operations of the apparatus are described below. The apparatus may be constructed, embodied or realized in various ways. For example, the apparatus may comprise at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform or carry out the respective functionalities or operations, the apparatus may comprise one or more means for performing or carrying out the respective functionalities or operations, the apparatus may comprise one or more circuitry for performing or carrying out the respective functionalities or operations, or the like. According to an example aspect, there is provided a method, comprising: transmitting (e.g. from a target master node to a target secondary node) a secondary-node addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with the target master node, receiving (e.g. by the target master node) information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node, and determining (e.g. at the target master node), based on said information, that the user equipment context is to be kept when the target secondary node is to be released from the preparation for the conditional handover of the user equipment for the target master node. Further potential steps or operations of the method are described below. According to an example aspect, there is provided an apparatus which is adapted, configured and / or operable to receive, by a source master node from a second target master node, a handover request acknowledgment message comprising information regarding preparation of a target secondary node for a conditional handover of a user equipment, determine, at the source master node, that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node, and transmit, from the source master node to at least one of a first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. Further potential functionalities or operations of the apparatus are described below. The apparatus may be constructed, embodied or realized in various ways. For example, the apparatus may comprise at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform or carry out the respective functionalities or operations, the apparatus may comprise one or more means for performing or carrying out the respective functionalities or operations, the apparatus may comprise one or more circuitry for performing or carrying out the respective functionalities or operations, or the like. According to an example aspect, there is provided a method, comprising: receiving (e.g. by a source master node from a second target master node) a handover request acknowledgment message comprising information regarding preparation of a target secondary node for a conditional handover of a user equipment, determining (e.g. at the source master node) that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node, and transmitting (e.g. from the source master node to at least one of a first target master node and the second target master node) information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. Further potential steps or operations of the method are described below. According to an example aspect, there is provided a system comprising at least two of the apparatuses according to any one of the aforementioned apparatus-related example aspects (and / or any development / modification thereof). According to an example aspect, there is provided a computer-readable medium comprising program instructions for causing an apparatus (e.g. an apparatus according to any one of the aforementioned apparatus-related example aspects (and / or any development / modification thereof)) to perform at least a method according to any one of the aforementioned method-related example aspects (and / or any development / modification thereof). According to an example aspect, there is provided a computer program product comprising (computer-executable) computer program code which, when the program code is executed (or run) on a computer or the program is run on a computer (e.g. a computer of an apparatus according to any one of the aforementioned apparatus-related example aspects (and / or any development / modification thereof)), is configured to cause the computer to carry out at least a method according to any one of the aforementioned method-related example aspects (and / or any development / modification thereof). The computer program product may comprise or may be embodied as a (tangible / non-transitory) computer-readable (storage) medium or the like, on which the computerexecutable computer program code is stored, and / or the program is directly loadable into an internal memory of the computer or a processor thereof. The term “non-transitory,” as used herein, is a limitation of the medium itself (referring to e.g. a tangible medium, not a signal) as opposed to a limitation on data storage persistency (e.g. RAM vs. ROM). Further developments and / or modifications of the aforementioned example aspects are set out in the following. By way of example embodiments, technique(s) for (e.g. enabling or otherwise facilitating or realizing ) conditional handover with target secondary node may be provided. This summary is intended to provide a brief overview of some of the aspects (and features thereof) according to the various example embodiments of the disclosure. Accordingly, it will be appreciated that the above-described aspects (and features thereof) are merely examples and should not be construed to narrow the scope of the various example embodiments or disclosure in any way. Other features, aspects, effects and / or purposes of the disclosure will become apparent from the following detailed description, drawings and claims. BRIEF DESCRIPTION OF THE DRAWINGS In the following, various example embodiments will be described with reference to the accompanying drawings, in which FIG. 1 shows a schematic diagram of an example (mobile / wireless) communication system or network; FIG. 2 shows a schematic diagram of an example wireless device or entity; FIG. 3 shows a schematic diagram of an example network node or entity; FIG. 4 shows a conditional handover procedure; FIG. 5 shows a dual-connectivity conditional handover procedure in a handover scenario; FIG. 6 shows a dual-connectivity conditional handover procedure in an overload scenario; FIGs. 7 to 11 each show a flowchart of an example method or process; FIGs. 12 to 17 each show an example dual-connectivity conditional handover procedure; FIG. 18 shows a schematic block diagram of a structure of apparatuses. DETAILED DESCRIPTION Various example embodiments are herein described with reference to particular non-limiting and illustrative examples. A person skilled in the art will appreciate that these various example embodiments are by no means limited to these non-limiting and illustrative examples, and may be more broadly applied. References in the specification to "one embodiment," "an embodiment," "an example embodiment," "some example embodiments," "certain example embodiments," "various example embodiments," and so forth, indicate that the referenced embodiment(s) may include particular feature(s), structure(s), or characteristic(s), but every referenced embodiment or example embodiment may not necessarily include the particular feature(s), structure(s), or characteristic(s). Moreover, such phrases are not necessarily referring to the same embodiment or example embodiment. Further, when particular feature(s), structure(s), or characteristic(s) are described in connection with an embodiment or an example embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with any other embodiments or example embodiments whether or not such combination(s) are explicitly described. It is to be noted that the detailed description, at times, refers to one or more specifications being used as non-limiting and illustrative examples for certain architectures, network configurations and system deployments. More specifically, the detailed description makes reference to 3GPP standards, being used as non-limiting and illustrative examples. As such, the example embodiments provided herein can specifically employ terminology which is directly related thereto. Such terminology is only used in the context of the non-limiting and illustrative examples, and is not intended to limit the example embodiments in any way. Rather, any other system configuration or deployment may be utilized while complying with what is described herein and / or example embodiments are applicable to it. For example, various example embodiments are applicable in any (e.g., mobile / wireless) communication system, such as a 5G / NR system and a next-generation / future system beyond 5G. For example, various example embodiments are applicable in a 3GPP-standardized mobile / wireless communication system of 3GPP Release 17 onwards. Furthermore, even though reference to 5G / NR is made, other types of access / system / network are supported / covered as well, such as future 3GPP radio / 6G but also non-3GPP access to 3GPP Core (such as e.g. Untrusted non-3GPP access to 3GPP core using e.g. N3IWF, Trusted non-3GPP access to 3GPP core using e.g. TNGF, wireline access to 3GPP core using e.g. W-AGF), or the like. When reference is made to particular terminology specific for any such example system, these references are to be understood / construed to be more generally applicable in a corresponding, similar or equivalent meaning. More specifically, when reference is made to some network function, entity or element of a 5G / NR or 3GPP system, it shall be understood / construed that any network function, entity or element of any system is meant or encompassed, which has or exhibits a corresponding, similar or equivalent characteristic, functionality, purpose or the like. As an illustrative but non-exhaustive example, a reference to master and secondary nodes shall mean or encompass any network function, entity or element of any communication network, which has or exhibits a characteristic, functionality, purpose or the like, which is corresponding, similar or equivalent to that of the referenced master and secondary nodes, respectively. Also, a master node shall mean or encompass any node in / of a higher (logical) level, which is able to control, assign, etc. any node in / of a lower (logical) level, which is denoted as secondary node, wherein a mater node and a secondary node can provide for dual connectivity of a network function, entity or element such as a UE. Hereinafter, various example embodiments are described using several variants and / or alternatives. It is generally to be noted that, according to certain implementations or constraints, all of the described variants and / or alternatives may be provided alone or in any conceivable combination (e.g. also including combinations of individual features of these various variants and / or alternatives). As used herein, the words “comprising” and “including” should be understood as not limiting the example embodiments to consist of only those features that have been mentioned, and example embodiments may also contain, among other things, e.g. features, structures, units, modules, or the like, that have not been specifically mentioned. As used herein, “at least one of the following: ” and “at least one of ” and similar expressions, like “one or more of’, where the list of two or more elements are joined by “and” or “or”, mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements. As used herein, the expression “and / or” mean at least any one of the elements, or at least any two or more of the elements, or at least all of the elements. As used herein, unless to explicitly stated to the contrary, performing a step / operation / functionality “in response to A” does not indicate that the step / operation / functionality is performed immediately after “A” occurs as one or more intervening steps / operations / functionalities may be included therebetween. Analogously, performing a step / operation / functionality “based on A” does not indicate that the step / operation / functionality is performed solely based on “A”, as the referenced step / operation / functionality may be further based on one or more other conditions (such as “B”) in addition to “A”. As used herein, according to various example embodiments, any operations of sending or receiving may comprise actual transmission or communication operations, e.g. transmitting or communicating associated information, data, signals or messages, but may additionally or alternatively comprise related processing operations, e.g. preparing / generating / issuing associated information, data, signals or messages before sending and / or obtaining / handling / processing of associated information, data, signals or messages after receiving. For example, sending an information or data at / by a node may comprise generating / issuing and / or transmitting / communicating thereof or a corresponding signal or message in / at / by the node, and receiving a signal or message at / by a node may comprise obtaining / handling and / or processing thereof or a corresponding information or data in / at / by the node. As used herein, a signal or message may refer to and / or encompass any kind of corresponding information, data, signal or the like. In the drawings, it is to be noted that lines / arrows interconnecting individual blocks or entities are generally meant to illustrate an operational coupling there-between, which may be a physical and / or logical coupling, which on the one hand is implementation-independent (e.g. wired or wireless) and on the other hand may also comprise an arbitrary number of intermediary functional blocks or entities not shown. In flowcharts or sequence diagrams, the illustrated order of operations or actions is generally non-limiting and illustrative, and any other order of respective operations or actions is conceivable, if feasible. Various example embodiments relate to considerations in a (e.g. mobile / wireless) communication system or network, such as a 5G / NR system and a next-generation / future system beyond 5G. For example, various example embodiments are applicable in a 3GPP-standardized mobile / wireless communication system or network of 3GPP Release 17 onwards. Such considerations relate to conditional handover of / for a user equipment, specifically (but not exclusively) in connection with dual connectivity using master and secondary nodes. Before explaining example embodiments in further detail, certain general aspects of a (mobile / wireless) communication system or network are briefly explained with reference to FIGS. 1 to 3 to assist in understanding the technology underlying the described example embodiments. FIG. 1 illustrates an example of a (mobile / wireless) communication system or network 100 that may be used for wireless communications. The communication system or network 100 includes wireless devices or entities, such as UEs 110 (e.g., 110A-110C), and network nodes or entities, such as radio access nodes 120 (e.g., 120A-120B) (e.g., eNBs, gNBs, and so forth), connected to one or more network nodes or entities 130 via an interconnecting network 125. The communication system or network 100 may use any suitable deployment scenarios. UEs 110 within coverage area 115 may each be capable of communicating directly with radio access nodes 120 over a wireless interface. In some example embodiments, UEs 110 may also be capable of communicating with each other via device-to-device (D2D) communication. As an example, UE 110A may communicate with radio access node 120A over a wireless interface. That is, UE 110A may transmit wireless signals to and / or receive wireless signals from radio access node 120A. The wireless signals may contain voice traffic, data traffic, control signals, and / or any other suitable information. As used herein, the term "user equipment" (UE) has the full breadth of its ordinary meaning and may refer to any type of wireless device or entity which can communicate with a network node or entity and / or with another UE in a cellular or mobile or wireless / mobile communication system. Examples of UEs are target device, D2D UE, machine type UE or UE capable of machine-to-machine (M2M) communication, personal digital assistant, tablet, mobile terminal, smartphone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, ProSe UE, vehicle-to-vehicle (V2V) UE, V2X UE, machine-type-communication (MTC) UE, eMTC UE, FeMTC UE, UE Cat 0, UE Cat Ml, narrow band loT (NB-Internet-of-Things) UE, UE Cat NB1, and so forth. Example embodiments of a UE are described in more detail below with respect to FIG. 2. In some example embodiments, an area of wireless signal coverage 115 associated with a radio access node 120 may be referred to as a cell. However, particularly with respect to the fifth generation (5G) / New Radio (NR) mobile communication concepts, beams may be used instead of cells and, as such, it is important to note that concepts described herein are equally applicable to both cells and beams. With respect to a beam-based mobile communication system, the radio access node 120 (base station) may transmit a beamformed signal to the UE 110 in one or more transmit directions (transmission beam, Tx beam). The UE 110 may receive the beamformed signal from the base station 120 in one or more receive directions (reception beam, Rx beam). The UE 110 may also transmit a beamformed signal to the base station 120 in one or more directions and the base station 120 may receive the beamformed signal from the UE 110 in one or more directions. The base station 120 and the UE 110 may determine the best receive and transmit directions, e.g., best in the sense of these directions leading to the highest link quality or fulfilling other quality conditions in the most suitable manner, for each of the base station / UE pairs. The interconnecting network 125 may refer to any interconnecting system capable of transmitting audio, video, signals, data, messages, and so forth, or any combination of the preceding. The interconnecting network 125 may include all or a portion of a public switched telephone network (PSTN), a public or private data network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a local, regional, or global communication or computer network, such as the Internet, a wireline or wireless network, an enterprise intranet, or any other suitable communication link, including combinations thereof. In some example embodiments, the network node 130 may be a core network node, managing the establishment of communication sessions and other various other functionalities for UEs 110. Examples of network node 130 may include mobile switching center (MSC), MME, serving gateway (SGW), packet data network gateway (PGW), operation and maintenance (O&M), operations support system (OSS), SON, positioning node (e.g., Enhanced Serving Mobile Location Center, E-SMLC), location server node, MDT node, and so forth. UEs 110 may exchange certain signals with the network node 130 using the non-access stratum (NAS) layer. In non-access stratum signaling, signals between UEs 110 and the network node 130 may be transparently passed through the radio access network. In some example embodiments, radio access nodes 120 may interface with one or more network nodes 130 over an internode interface. As used herein, the term "network node or entity" has the full breadth of its ordinary meaning and may correspond to any type of radio access node (or radio network node) or any network node, which can communicate with a UE and / or with another network node in a cellular or mobile or wireless communication system. Examples of network nodes are NodeB, MeNB, SeNB, a network node may belonging to master cell group (MCG) or secondary cell group (SCG), base station (BS), multi-standard radio (MSR) radio access node, such as MSR BS, eNodeB, network controller, radio network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), access point (AP), transmission point, transmission node, RRU, RRH, node in distributed antenna system (DAS), core network node (e.g., MSC, MME, and so forth), O&M, OSS, Self-organizing Network (SON), positioning node (e.g., E-SMLC), MDT, test equipment, and so forth. Example embodiments of a network node are described in more detail below with respect to FIG. 3. In some example embodiments, radio access node 120 may be a distributed radio access node. The components of the radio access node 120, and their associated functions, may be separated into two main units (or sub-radio network nodes) which may be referred to as the central unit (CU) and the distributed unit (DU). Different distributed radio network node architectures are possible. For instance, in some architectures, a DU may be connected to a CU via dedicated wired or wireless link (e.g., an optical fiber cable) while in other architectures, a DU may be connected a CU via a transport network. Also, how the various functions of the radio access node 120 are separated between the CU(s) and DU(s) may vary depending on the implemented architecture. Example wireless communication systems are architectures standardized by the 3rd Generation Partnership Project (3GPP). A 3GPP based development is often referred to as the long-term evolution (LTE) of the Universal Mobile Telecommunications System (UMTS) radio-access technology (RAT). The various development stages of the 3GPP specifications are referred to as releases. More recent developments of the LTE are often referred to as LTE Advanced (LTE-A). The LTE (LTE-A) employs a radio mobile architecture known as the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) and a core network known as the Evolved Packet Core (EPC). Base stations of such systems are known as evolved or enhanced Node Bs (eNBs) and provide E-UTRAN features, such as user plane Packet Data Convergence / Radio Link Control / Medium Access Control / Physical layer protocol (PDCP / RLC / MAC / PHY) and control plane Radio Resource Control (RRC) protocol terminations towards the communication devices. Other RAT examples comprise those provided by base stations of systems that are based on technologies, such as WLAN and / or Worldwide Interoperability for Microwave Access (WiMax). A base station can provide coverage for an entire cell or similar radio service area. Core network elements include Mobility Management Entity (MME), Serving Gateway (S-GW) and Packet Gateway (P-GW). An example of a suitable communications system is the 5G / 6G or NR concept. Network architecture in NR may be similar to that of LTE-A. Base stations of NR systems may be known as next generation Node Bs (gNBs). Changes to the network architecture may depend on the support for various radio technologies and finer Quality of Service (QoS), and some on-demand requirements for QoS levels to support Quality of Experience (QoE) of user point of view. Also network aware services and applications, and service and application aware networks may bring changes to the network architecture. Those are related to Information Centric Network (ICN) and User-Centric Content Delivery Network (UC-CDN) approaches. NR may use multiple input-multiple output (MIMO) antennas, many more base stations or nodes than the LTE (a so-called small cell concept), including macro sites operating in cooperation with smaller stations and perhaps also employing a variety of radio technologies for enhanced (e.g., better, increased, and so forth) coverage and data rates. Future networks may utilize network functions virtualization (NFV), which is a network architecture concept that proposes virtualizing network node functions into "building blocks" or entities that may be operationally connected or linked together to provide services. A virtualized network function (VNF) may comprise one or more virtual machines running computer program code using standard or general type servers instead of customized hardware. Cloud computing or data storage may also be utilized. In radio communications, this may mean node operations are to be carried out, at least partly, in a server, host or node operationally coupled to a remote radio head. It is also possible that node operations will be distributed among a plurality of servers, nodes, or hosts. It should also be understood that the distribution of labor between core network operations and base station operations may differ from that of the LTE or even be non-existent. An example 5G core network (CN) comprises functional entities. The CN is connected to a UE via the radio access network (RAN). An UPF (User Plane Function) whose role is called PSA (PDU Session Anchor) may be responsible for forwarding frames back and forth between the DN (data network) and the tunnels established over the 5G network towards the UEs exchanging traffic with the data network (DN). The UPF is controlled by an SMF (Session Management Function) that receives policies from a PCF (Policy Control Function). The CN may also include an AMF (Access &Mobility Function). Generally, all concepts disclosed herein may be applicable to different communication networks, comprising but not limited to LTE, LTE-A, 5G, 5G advanced, 6G, and other future or already implemented networks. FIG. 2 is a schematic diagram of an example wireless device, UE 110, according to certain example embodiments. UE 110 may include one or more of at least one transceiver 210, at least one processor 220, at least one memory 230, and at least one network interface 240. In certain example embodiments, the transceiver 210 facilitates transmitting wireless signals to and receiving wireless signals from radio access node 120 (e.g., via transmitted s) (Tx), receiver(s) (Rx) and antenna(s)). The processor(s) 220 execute instructions to provide some or all of the functionalities described herein as being provided by a wireless device / entity or UE, and the memory 230 stores the instructions executed by the processor(s) 220. In some embodiments, the processor(s) 220 and the memory 230 form processing circuitry. The processor(s) 220 may include any suitable combination of hardware to execute instructions and manipulate data to perform some or all of the described functions of a wireless device or entity, such as the functions of UE 110 described herein. In some embodiments, the processor(s) 220 may include, for example, one or more computers, one or more central processing units (CPUs), one or more microprocessors, one or more application specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs) and / or other logic. The memory 230 is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, and so forth and / or other instructions capable of being executed by a processor 220. Examples of memory 230 include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or or any other volatile or non-volatile, non- transitory computer-readable and / or computerexecutable memory devices that store information, data, and / or instructions that may be used by the processor 220 of UE 110. For example, the memory 230 includes computer program code causing the processor 220 to perform processing according to any corresponding methods (or portions thereof) described herein. The network interface 240 is communicatively coupled to the processor 220 and may refer to any suitable device operable to receive input for UE 110, send output from UE 110, perform suitable processing of the input or output or both, communicate to other devices, or any combination thereof. The network interface 240 may include appropriate hardware (e.g., port, modem, network interface card, and so forth) and software, including protocol conversion and data processing capabilities, to communicate through a network. Other example embodiments of UE 110 may include additional components beyond those shown in FIG. 2 that may be responsible for providing certain aspects of the wireless device’s functionalities, including any of the functionalities described herein and / or any additional functionalities (including any functionality to support the mechanisms according to the disclosure). As an example, UE 110 may include input devices and circuits, output devices, and one or more synchronization units or circuits, which may be part of the processor(s) 220. Input devices include mechanisms for entry of data into UE 110. For example, input devices may include input mechanisms, such as a microphone, input elements, a display, and so forth. Output devices may include mechanisms for outputting data in audio, video and / or hard copy format. For example, output devices may include a speaker, a display, and so forth. In certain example embodiments, the wireless device UE 110 may comprise a series of modules configured to implement the functionalities of the wireless device described herein. It will be appreciated that the various modules may be implemented as combination of hardware and software, for instance, the processor, memory, and transceiver(s) of UE 110 shown in FIG. 2. Certain example embodiments may also include additional modules to support additional and / or optional functionalities. FIG. 3 is a schematic diagram of an example radio access node 120 or network node or entity 130 according to certain example embodiments. Radio access node 120 or network node or entity 130 may include one or more of at least one transceiver 310, at least one processor 320, at least one memory 330, and at least one network interface 340. In certain example embodiments, the transceiver(s) 310 facilitate transmitting wireless signals to and receiving wireless signals from wireless devices, such as UE 110 (e.g., via transmitted s) (Tx), receiver(s) (Rx), and antenna(s)). The processor(s) 320 execute instructions to provide some or all of the functionalities described herein as being provided by the radio access node 120 or the network node or entity 130, the memory 330 stores the instructions executed by the processor 320. In some example embodiments, the processor(s) 320 and the memory 330 form processing circuitry. The network interface(s) 340 can communicate signals to backend network components, such as a gateway, switch, router, Internet, Public Switched Telephone Network (PSTN), core network nodes or radio network controllers, and so forth. The processor 320 can include any suitable combination of hardware to execute instructions and manipulate data to perform some or all of the described functions of the radio access node 120 or the network node or entity 130, such as those described herein. In some example embodiments, the processor(s) 320 may include, for example, one or more computers, one or more central processing units (CPUs), one or more microprocessors, one or more application specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs) and / or other logic. The memory 330 is generally operable to store instructions, such as a computer program, software, an application including one or more of logic, rules, algorithms, code, tables, and so forth and / or other instructions capable of being executed by the processor(s) 320. Examples of memory 330 include computer memory (for example, Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (for example, a hard disk), removable storage media (for example, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or or any other volatile or non-volatile, non- transitory computer-readable and / or computerexecutable memory devices that store information. For example, the memory 330 includes computer program code causing the processor 320 to perform processing according to any corresponding methods (or portions thereof) described herein. In certain example embodiments, the network interface(s) 340 are communicatively coupled to the processor(s) 320 and may refer to any suitable device operable to receive input for the radio access node 120 or the network node or entity 130, send output from the radio access node 120 or the network node or entity 130, perform suitable processing of the input or output or both, communicate to other devices, or any combination of the preceding. The network interface 340 may include appropriate hardware (e.g., port, modem, network interface card, and so forth) and software, including protocol conversion and data processing capabilities, to communicate through a network. Other example embodiments of the radio access node 120 or the network node or entity 130 can include additional components beyond those shown in FIG. 3 that may be responsible for providing certain aspects of the node’s functionalities, including any of the functionalities described herein and / or any additional functionalities (including any functionality to support the solutions described herein). The various different types of radio access nodes or network nodes may include components having the same physical hardware but configured (e.g., via programming) to support different radio access technologies, or may represent partly or entirely different physical components. Processors, interfaces, and memory similar to those described with respect to FIG. 3 may be included in other nodes or entities (such as UE 110, radio access node 120, and so forth). Other nodes or entities may optionally include or not include a wireless interface (such as the transceiver(s) described in FIG. 3). In certain example embodiments, the radio access node 120 or the network node or entity 130 may comprise a series of modules configured to implement the functionalities of the radio access node 120 or the network node or entity 130 described herein. It will be appreciated that the various modules may be implemented as combination of hardware and software, for instance, the processor(s), memory, and transceiver(s) of the radio access node 120 or the network node or entity 130 shown in FIG. 3. Certain example embodiments may also include additional modules to support additional and / or optional functionalities. It should be noted that all concepts described herein, although described in a specific manner or context, may be more generally applicable, e.g. in another specific manner or context, as will be apparent to the skilled person. Before referring to FIGS. 7 to 18 and describing specifics of technique(s) for (e.g. enabling / facilitating / realizing) conditional handover of / for a UE with target secondary node, some additional information and aspects related to certain example embodiments will be provided. A Conditional Handover (CHO) is defined as a handover that is executed by the UE when one or more handover execution conditions are met. The UE starts evaluating the execution condition(s) upon receiving a CHO configuration, and the UE stops evaluating the execution condition(s) once a handover is executed. Thereby, the UE can decide to perform handover, in contrast to legacy handover where the network is in charge of making the decision whether the handover should be performed or not based on measurement report(s) received from the UE. For CHO, a set of possible target nodes (such as e.g. radio access node 120 in the system / network of FIG. 1) and / or cells (such as e.g. coverage area 115 in the system / network of FIG. 1) are prepared, i.e. resources at a set of possible target nodes and / or cells are reserved, thus enabling UE-initiated handover without network involvement. In CHO 3GPP Release 16, UE is configured with a CHO command containing the target cell configuration and a condition to execute the handover for one or multiple prepared target cells. The condition is based on radio measurements of the neighboring cells. CHO is designed so that the UE can do the handover autonomously without the need for the serving cell to trigger the HO execution e.g., after receiving the measurement report(s) from the UE. FIG. 4 shows a conditional handover procedure. The thus illustrated handover procedure refers to legacy handover within a New Radio (NR) network. The steps of the conditional handover procedure shown in FIG. 4 are described in the following: • In step 1, the UE sends a measurement report to the serving / source gNB containing the measurement results for neighboring cells. • In step 2, the source node (e.g. gNB) identifies the need to trigger CHO. • In steps 3 and 4, the source node requests potential target nodes to provide CHO configurations for target cells under the control of the target nodes. The CHO configuration contains the radio protocol configurations that the UE shall apply when handing over to a target cell of a target node. • In steps 5 and 6, the target nodes perform admission control and generate the CHO configurations that are provided back to the source node in steps 7 and 8. • The source node associates each CHO configuration with a CHO execution condition which refers to a measurement ID in source cell measurement configuration. The measurement ID links a measurement object defining the frequency and quantity of the measurement (RSRP (Reference Signal Received Power), RSRQ (Reference Signal Received Quality), etc.) with a reporting configuration defining the parameters of the event (offset, Time-to-Trigger (TTT) or thresholds) triggering the execution of CHO. For intra-frequency handover, the measurement event A3 is used, e.g., Mn >Ms+ Off where Mn is the measurement of neighboring cell, Ms is the measurement of a target cell and Off is an offset. Herein, the UE will execute the CHO in case the condition above is met for a certain Time-to-Trigger (TTT). For inter-frequency HO, measurement event A5 can be used where the UE checks if the measurement of the serving cell falls below a first threshold and the measurement of the target cell is better than a second threshold for a certain TTT. The details of the measurement configuration and event can be found in 3GPP TS 38.331. • In step 9, the source node sends the CHO configurations of the prepared target cells along with their corresponding CHO execution condition. • In step 10, the UE evaluates the CHO execution conditions and, if one of them is met for a prepared target cell of one of the target nodes, as shown in step 11, the UE applies the corresponding CHO configuration and executes the handover as shown in steps 12-19 which are known to a person skilled in the art. In step 19, the source node cancels the CHO preparations of the target cells of the target nodes that have not been used / applied (or selected) by the UE for handover execution. • The path switch from source node to target node is performed in step 20. A Conditional Handover (CHO) is also allowed for UEs configured with dual (or multiple) connectivity, which may also be referred to as conditional handover with target secondary node. That is, a dual / multiple-connectivity UE, which has connectivity with one or more master nodes (each controlling a master cell group (MCG)) and one or more secondary nodes (each controlling a secondary cell group (SCG)), can perform CHO from a source master node (MN) to a target master node (MN) and / or a target secondary node (SN) being controlled by the target master node (MN). Herein, the source MN (controlling Primary Cell, PCell) sends a handover request to the target MN (controlling target PCell) which in turn selects a target SN (controlling target PSCell) and prepares it as part of the CHO preparation, in addition to preparing a PCell candidate. When the CHO execution condition is met, the UE performs handover from the source MN to that target MN and SN, thus accessing the target PCell and the target PSCell. One of the main differences between the legacy handover (as defined in 3 GPP Release 15) and the conditional handover (as defined in 3GPP Release 16) is the preparation of the multiple target nodes / cells. CHO is expected to be configured earlier compared to legacy handover to make sure that the UE has a prepared target nodes / cells when the execution condition is met. This means CHO reserves more resources (in time and in number of cells) than legacy handover while the UE is waiting for the execution. In case of multiple preparations, each of the target MNs may prepare its own target SN / SNs. Each target SN will therefore have to reserve the needed resources, too. Since each of the target MNs receives the same measurements, it may occur that they both decide to prepare the same target SN. Using recent enhancements introduced by 3GPP to CHO in Release 17 the target SN is able to detect that SN Addition Requests (possibly from different target MNs) are related to the same UE. Moreover, by comparing the SCG configurations, the target SN is able to recognize that the target MNs have provided the same configuration for SN terminated bearers. In MR-DC (Multi-Radio Dual Connectivity), QoS flows (which carry user plane data) belonging to the same session may be mapped to one or more different bearer types. These are: master cell group (MCG) bearer, secondary cell group (SCG) bearer and split bearer. An MCG bearer is a radio bearer with one or more RLC bearers only in the master cell group. An SCG bearer is a radio bearer with one or more RLC bearers only in the secondary cell group. A split bearer is a radio bearer with one or more RLC bearers in the master cell group and one or more RLC bearers in the secondary cell group. Put in other terms, for MCG bearers only the radio resources of MCG are involved, whereas for SCG bearers only the SCG radio resources are involved. In the case of split bearers, both MCG and SCG radio resources are involved. A split bearer can be used for duplication or load balancing between RAN nodes. For duplication, the use case can be to provide high reliability or low interruption time for a particular service. More information on the definition of bearers can be found in 3GPP TS 37.340. When working on dual-connectivity (DC) or multi-connectivity, a scenario is considered, where the UE is configured with DC operation at the source MN. The source MN may decide to configure one or more target MNs for the UE for CHO. In turn, the one or more target MNs may decide to add the same or different one or more target SNs for the UE. The target MN(s) are enabled to provide enough information to the target SN so that the target SN can identify that a UE context (of / for the UE for which CHO is prepared) already exists from a previous target MN configuration related to CHO for the UE. When CHO is completed and the UE has handed over to one of the one or more prepared target MNs, the source MN releases the target MNs that were not selected by the UE. In turn, the target MNs may release the UE context for that UE towards the prepared target SN.. Since the target SN knows that the UE context is shared with one or more target MNs, it could avoid removing it completely by own implementation knowing that there is still one target MN in use for which the UE context should be kept for the UE to continue operating in dual- or multi-connectivity. Nonetheless, it is specified and common understanding within 3GPP community that this is not appropriate and that target SN’s behavior should depend on the context of a particular interface, not to be related to the situation with other nodes. Hence, it was agreed within 3GPPP to add a flag to the release message that informs the target SN that it shall remove only part of the UE context relevant for the communication with the source MN. FIG. 5 shows a dual-connectivity conditional handover procedure in a handover scenario, in which of one of target MNs prepared for the UE for dual connectivity (i.e., Target MN1) is selected for conditional handover. As shown in FIG. 5, it can occur that a source MN might prepare multiple target MNs for CHO of a UE. In turn, each of the target MNs might prepare multiple target SNs. Some of the target SNs might be prepared by one or more target MNs. In the example of FIG. 5, target SN1 is prepared by both target MN 1 and target MN2. When the UE performs CHO and is successfully handed over in one of the target cells prepared by one of the target MNs, then the source MN is sending a Handover Cancel Request to other target MNs that were prepared for the CHO but not selected by the UE. In turn, the target MN that was not selected will initiate an SN Release Request towards the prepared target SNs. However, it can occur that selected and non-selected target MNs have prepared the same target SN. As they are not aware of this fact, the non-selected target MN would release (its prepared resources for the UE at) a common target SN. This would however be a wrong / undue release of the target SN resources for the UE, since the target SN is still needed by / for the selected target MN by the UE for dual connectivity. In the example of FIG. 5, it is assumed that target MN1 is selected for the CHO of the UE such that the Handover Cancel Request is sent to target MN2, and target MN2 then releases its prepared target SNs (i.e., releases the UE context at its prepared target SNs) including target SN1 which is prepared by both target MN1 and target MN2. FIG. 6 shows a dual-connectivity conditional handover procedure in an overload scenario, in which of one of target MNs prepared for the UE for dual connectivity (i.e., Target MN2) is overloaded. The underlying configuration in the example of FIG. 6 corresponds to that of FIG. 5. However, in the example of FIG. 6, it is not assumed that a CHO takes place and release of the common target SN is triggered by a Handover Cancel Request. Rather, it can occur that one of the target MNs might be overloaded. Then, the overloaded target MN would send a CHO Cancel Request to the source MN, and release (its MN’s prepared resources at) the target SNs prepared for the UE for that target MN. As the overloaded target MN is not aware of any commonly prepared target SN by other potential target MNs, it would also release (its prepared resources at) a common target SN (i.e., release the UE context at the common target SN). This would however be a wrong / undue release of the target SN, since the target SN is still needed by / for the selected target MN by the UE for the operation of the UE in dual connectivity. In the example of FIG. 6, it is assumed that target MN2 is overloaded, and target MN2 then releases its prepared target SNs (i.e., releases the UE context at its prepared target SNs) including target SN1 which is prepared by both target MN1 and target MN2. Accordingly, in dual-connectivity conditional handover procedures, there is an issue that, either due to handover (as, by way of example, illustrated in FIG. 5) or overload (as, by way of example, illustrated in FIG. 6), a target SN being prepared by multiple target MNs, that in fact is needed, might be released which may result in termination of UE operations in dual / multiple connectivity and require extra signaling until it is re-established by the selected or non-overloaded target MN of the UE for dual connectivity. In view of the above, the technique(s) disclosed herein refers to at least part of such aspects, issues or considerations which are exemplified in the context of a 5G / NR system. The technique(s) disclosed herein generally refer to conditional handover with target secondary node. It is to be noted conditional handover with target secondary node may herein also be referred to as conditional handover under dual or multiple connectivity, e g. conditional handover of / for a user equipment configured with dual or multiple connectivity using master and secondary nodes (of a communication network / system). While reference may herein be made to dual connectivity, it is to be noted that this is not intended as a limitation to only two-fold connectivity but shall encompass any kind of multiple connectivity (which may also be referred to as multi-connectivity). Hereinafter, various example embodiments of the disclosure are further explained. For illustrative purposes, the description of example embodiments is based on the assumption of a conditional handover (CHO) scenario in which at least a first target master node and a second target master node are prepared for conditional handover of a user equipment (which is currently served by a source master node). In this regard, preparation of a target (master or secondary) node for CHO of a user equipment may mean or encompass that corresponding / necessary resources are reserved for the UE at the target (master or secondary) node and / or a TEID for a data flow is assigned (for serving the user equipment after handover) at the target (master or secondary) node. The first and second target master nodes and the target secondary node are configured to provide dual connectivity for the user equipment. FIG. 7 shows a flowchart of an example method or process according to at least one example embodiment. This example method or process may be performed or carried out at / by an apparatus. The apparatus may implement (at least in part) a target secondary node or, stated in other words, the method or process may be a method or process of (or, stated in other words, operable or for use in / by) a target secondary node. The target secondary node may be an example of a network function, entity or element of a communication system in the aforementioned conditional handover scenario. As shown in FIG. 7, the method or process may comprise a step / operation (SI 10) of receiving, from a second target master node, a secondary-node addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with the second target master node, a step / operation (S120) of determining, that the target secondary node is already prepared for the conditional handover of the user equipment by identifying that the user equipment context exists in association with a first target master node, and a step / operation (S130) of transmitting, to at least one of the first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. Further modifications, variants and details of this method or process become apparent from the further description. FIG. 8 shows a flowchart of an example method or process according to at least one example embodiment. This example method or process may be performed or carried out at / by an apparatus. The apparatus may implement (at least in part) target secondary node or, stated in other words, the method or process may be a method or process of (or, stated in other words, operable or for use in / by) a target secondary node. The target secondary node may be an example of a network function, entity or element of a communication system in the aforementioned conditional handover scenario. As shown in FIG. 8, the method or process may comprise a step / operation (S210) of receiving, from one of the first target master node and the second target master node, a secondary-node release request message comprising an indication that the user equipment context is to be kept, a step / operation (S220) of determining that the target secondary node remains prepared only for the conditional handover with regard to the user equipment context in association with the other one of the first target master node and the second target master node, and a step / operation (S230) of transmitting, to the other one of the first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover only for the other one of the first target master node and the second target master node. Further modifications, variants and details of this method or process become apparent from the further description. FIG. 9 shows a flowchart of an example method or process according to at least one example embodiment. This example method or process may be performed or carried out at / by an apparatus. The apparatus may implement (at least in part) target master node or, stated in other words, the method or process may be a method or process of (or, stated in other words, operable or for use in / by) a target master node. The target master node may be an example of a network function, entity or element of a communication system in the aforementioned conditional handover scenario. As shown in FIG. 9, the method or process may comprise a step / operation (S310) of transmitting, to a target secondary node, a secondary-node addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with to the target master node, a step / operation (S320) of receiving information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node, and a step / operation (S330) of determining, based on said information, that the user equipment context is to be kept when the target secondary node is to be released from the preparation for the conditional handover of the user equipment for the target master node. Further, as indicated by dashed lines, the method or process may comprise a step / operation (S340) of transmitting, to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept. Further modifications, variants and details of this method or process become apparent from the further description. FIG. 10 shows a flowchart of an example method or process according to at least one example embodiment. This example method or process may be performed or carried out at / by an apparatus. The apparatus may implement (at least in part) or target master node, stated in other words, the method or process may be a method or process of (or, stated in other words, operable or for use in / by) a target master node. The target master node may be an example of a network function, entity or element of a communication system in the aforementioned conditional handover scenario. As shown in FIG. 10, the method or process may comprise a step / operation (S410) of receiving, from the target secondary node, information indicating that the target secondary node is prepared for the conditional handover only for the target master node, and a step / operation (S420) of determining, based on said information, that the user equipment context is to be released when the target secondary node is to be released from the preparation for the conditional handover for the target master node. Further modifications, variants and details of this method or process become apparent from the further description. FIG. 11 shows a flowchart of an example method or process according to at least one example embodiment. This example method or process may be performed or carried out at / by an apparatus. The apparatus may implement (at least in part) source master node or, stated in other words, the method or process may be a method or process of (or, stated in other words, operable or for use in / by) a source master node. The source master node may be an example of a network function, entity or element of a communication system in the aforementioned conditional handover scenario. As shown in FIG. 11, the method or process may comprise a step / operation (S510) of receiving, from a second target master node, a handover request acknowledgment message comprising information regarding preparation of a target secondary node for a conditional handover of a user equipment, a step / operation (S520) of determining that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node, and a step / operation (S530) of transmitting, to at least one of a first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. Further modifications, variants and details of this method or process become apparent from the further description. Any one of the methods or processes can be performed in or for or be part of a dual connectivity-procedure, also referred to as conditional handover with secondary node procedure. The methods or processes of FIGs. 7 to 11 may be arbitrarily combined, as far as conceivable or practicable. While FIGS. 7 to 11 shows methods or processes, it is to be noted that there are also provided corresponding apparatuses which are adapted, configured and / or operable to perform the thus described steps or operations. In an example embodiment, functionalities of nodes may be as follows. It is to be noted that the individual nodes and / or functionalities described below may be embodied individually and / or in any conceivable combination. A target secondary node may receive, e.g. from a second target master node, a secondarynode addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with the second target master node. The target secondary node may determine that the target secondary node is already prepared for the conditional handover of the user equipment by identifying that the user equipment context exists in association with a first target master node. The target secondary node may transmit, e.g. to at least one of the first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. The target secondary node may transmit, e.g. to the second target master node, a secondarynode addition request acknowledgment message comprising said information. The information may comprise: an information that the user equipment context also exists in association with the first target master node, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes. A target master node may transmit, e.g. to a target secondary node, a secondary-node addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with to the target master node. The target master node may receive information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. The target master node may determine, based on said information, that the user equipment context is to be kept when the target secondary node is to be released from the preparation for the conditional handover of the user equipment for the target master node. The target master node may receive, e.g. from a source master node, a handover cancel request message comprising said information. The target master node may transmit, e.g. from to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept. The target master node may receive, e.g. from the source master node, a message comprising said information. The message may be a handover cancel request message further comprising a cause code or indication indicating that the message does not request handover cancellation and / or the message is to notify about said information. The target master node may determine that the target master node is overloaded. The target master node may transmit, e.g. to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept. The information (which may e,g, received in a handover cancel request) may comprise: an information that the user equipment context should not be released, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes. The target master node may transmit, e.g. to the source master node, a list or set of target secondary nodes being prepared for the conditional handover for the target master node. The target master node may receive, e.g. from the target secondary node, a secondary-node addition request acknowledgment message comprising said information. The target master node may transmit, e.g. to the source master node, a handover request acknowledgment message comprising said information or a list or set of target secondary nodes being prepared for the conditional handover for the target master node. The information may comprise: an information that the user equipment context also exists for another target master node, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes. The target master node may receive, e.g. from the source master node, a handover cancel request message, and / or may transmit, e.g. to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept. The target master node may determine that the target master node is overloaded, and / or may transmit, e.g. to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept. A source master node may receive, e.g. from a second target master node, a handover request acknowledgment message comprising information regarding preparation of a target secondary node for a conditional handover of a user equipment. The source master node may determine that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. The source master node may transmit, e.g. to at least one of a first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. The information regarding preparation of a target secondary node for the conditional handover may comprise a list or set of target secondary nodes being prepared for the conditional handover for the second master node. The source master node may receive, e.g. from the first target master node, a list or set of target secondary nodes being prepared for the conditional handover for the first master node. The source master node may determine that the target secondary node is prepared for the conditional handover for more than one target master node by comparing the lists or sets received from the first target master node and a second target master node. The information regarding preparation of a target secondary node for the conditional handover may comprise: an information that a user equipment context, in association with which the target secondary node is prepared for the conditional handover, also exists in association with the first target master node, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes. The source master node may determine that the target secondary node is prepared for the conditional handover for more than one target master node based on said information. The source master node may determine that the first target master node is not selected as target for the conditional handover of the user equipment. The source master node may transmit a handover cancel request message comprising the information indicating that the target secondary node is prepared for the conditional handover for more than one target master node. The source master node may transmit, e.g. to first target master node, a message comprising the information indicating that the target secondary node is prepared for the conditional handover for more than one target master node. The message may be a handover cancel request message further comprising a cause code or indication indicating that the message does not request handover cancellation and / or the message is to notify about said information. In an example embodiment, functionalities of nodes may be as follows. It is to be noted that the individual nodes and / or functionalities described below may be embodied individually and / or in any conceivable combination. A target secondary node may receive, e.g. from a second target master node, a secondarynode addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with the second target master node. The target secondary node may determine that the target secondary node is already prepared for the conditional handover of the user equipment by identifying that the user equipment context exists in association with a first target master node. The target secondary node may transmit, e.g. to at least one of the first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. The target secondary node may transmit, e.g. to the second target master node, a secondarynode addition request acknowledgment message comprising said information, and / or may transmit, e.g. to the first target master node, a secondary-node modification request message comprising said information. The information in the secondary-node addition request acknowledgment message may comprise: an information that the user equipment context also exists in association with the first target master node, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes. The information in the secondary-node modification request message may comprise: an information that the user equipment context also exists in association with the second target master node, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes. A target master node may transmit, e.g. to a target secondary node, a secondary-node addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with to the target master node. The target master node may receive information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. The target master node may determine, based on said information, that the user equipment context is to be kept when the target secondary node is to be released from the preparation for the conditional handover of the user equipment for the target master node. The target master node may receive, e.g. from the target secondary node, a secondary-node addition request acknowledgment message comprising said information or a secondary-node modification request message comprising said information. The information may comprise: an information that the user equipment context also exists for another target master node, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes. The target master node may receive, e.g. from the source master node, a handover cancel request message, and / or may transmit, e.g. to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept. The target master node may determine that the target master node is overloaded, and / or may transmit, e.g. to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept. In an example embodiment, functionalities of nodes may be as follows. It is to be noted that the individual nodes and / or functionalities described below may be embodied individually and / or in any conceivable combination. A target secondary node may receive, e.g. from one of the first target master node and the second target master node, a secondary-node release request message comprising an indication that the user equipment context is to be kept. The target secondary node may determine that the target secondary node remains prepared only for the conditional handover with regard to the user equipment context in association with the other one of the first target master node and the second target master node. The target secondary node may transmit, e.g. to the other one of the first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover only for the other one of the first target master node and the second target master node. The target secondary node may perform the above operations after the target secondary node may have received, e.g. from a second target master node, a secondary-node addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with the second target master node, may have determine that the target secondary node is already prepared for the conditional handover of the user equipment by identifying that the user equipment context exists in association with a first target master node, and / or may have transmitted, e.g. to at least one of the first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. The target secondary node may transmit, e.g. to the other one of the first target master node and the second target master node, a secondary-node modification request message comprising said information. The information may comprise: an information that the user equipment context exists only in association with the other one of the first target master node and the second target master node, or a flag or indication indicating that the target secondary node is not shared among multiple target master nodes. The secondary-node release request message may comprise the indication that the user equipment context is to be kept is triggered by the one of the first target master node and the second target master node in response to the preparation for the conditional handover being cancelled or in response to being overloaded. A target master node may transmit, e.g. to a target secondary node, a secondary-node addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with to the target master node. The target master node may receive information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. The target master node may determine, based on said information, that the user equipment context is to be kept when the target secondary node is to be released from the preparation for the conditional handover of the user equipment for the target master node. The target master node may receive, e.g. from the target secondary node, information indicating that the target secondary node is prepared for the conditional handover only for the target master node. The target master node may determine, based on said information, that the user equipment context is to be released when the target secondary node is to be released from the preparation for the conditional handover for the target master node. The target master node may receive, e.g. from the target secondary node, a secondary-node modification request message comprising said information. The information may comprise: an information that the user equipment context exists only for the target master node, or a flag or indication indicating that the target secondary node is not shared among multiple target master nodes. It is to be noted that any message names used herein are not limiting bur merely illustrative. For example, a secondary-node addition request or SN Addition Request may be any message, signal, information or information element regarding preparation of a target secondary node for a conditional handover, a secondary-node addition request acknowledgment message or SN Request Ack may be any message, signal, information or information element responsive to any kind of a secondary-node addition request or SN Addition Request, a secondary-node modification request message or SN Modification Required may be any message, signal, information or information element regarding modification or change of preparation of a target secondary node for a conditional handover or a target master node relating to the target secondary node, a secondary-node release request message may be any message, signal, information or information element regarding release of a target secondary node (and / or resources reserved thereat and / or a UE context established thereat) from preparation for a conditional handover, a handover cancel request message may be any message, signal, information or information element regarding cancellation of preparation of a target master node for a conditional handover or may be any message, signal, information or information element which may be communicated for carrying information which might be usable in the context of cancellation of preparation of a target master node for a conditional handover. The above-described example embodiments encompass corresponding methods, each comprising one or more of the recited steps and / or operations, which may be performed or carried out at or by corresponding apparatuses, as well as corresponding apparatuses (which may represent or be part of or operable as, at or in one or more of the recited nodes), each being adapted, configured and / or operable to perform or carry out one or more of the recited steps and / or operations. Further details, examples, modifications and variants of the functionalities of the nodes being involved in the aforementioned conditional handover scenario are described hereinafter with regard to certain example use cases. For illustrative purposes, these example use cases are also based on the aforementioned conditional handover scenario. Specifically, it is assumed that, for a CHO of a UE, which is currently served by Source MN, there are prepared Target MN1, Target MN2, Target SN1 and Target SN2, wherein Target SN1 is a common SN being prepared by both Target MN1 and Target MN2, while Target SN2 is prepared by Target MN2 only. It is noted that the number of two MNs and two SNs is merely exemplary and illustrative for the ease of explanation, while any other numbers are equally applicable. Specifically, there may be more second target MNs, i.e. target MNs which request CHO preparation at one or more target SNs after a first target MN has already / previously requested such CHO preparation at the same and / or different one or more target SNs. FIG. 12 shows an example dual-connectivity conditional handover procedure according to at least one example embodiment. For this procedure, it is assumed that CHO of the UE takes place between steps 11 and 12 or between steps 12 and 13, and Target MN2 is selected (as target node) for the UE. As shown in FIG. 12, the example procedure may have the following steps: • Steps 1-2: Source MN prepares Target MN 1 and Target MN2 for the Conditional Handover of the UE o Source MN sends Handover Request to both Target MN1 and Target MN2 containing also CHO Request • Steps 3-4: Target MN1 prepares Target SN1 for the CHO of the UE o Target MN1 sends SN Addition Request to Target SN1 o Target SN1 is prepared for the CHO of the UE, including e.g. reserving resources for the UE for the CHO and establishing a UE context (of the UE) for (in association with) Target MN1 o Target SN1 replies to Target MN1 with SN Addition Request Ack upon completion of its preparation • Step 5: Target MN 1 replies back to source MN with HO Request Ack, which may comprise a list of prepared target SNs for Target MN1 • Steps 6-10: Target MN2 prepares Target SN1 and Target SN2 for the CHO of the UE o Target MN2 sends SN Addition Request to Target SN1 and Target SN2 o Target SN 1 determines that there already exists the UE context (of the UE) for (in association with) Target MN1, i.e. there are already resources received for the UE for another target MN (i.e., Target MN 1) o Target SN1 provides in the responsive SN Addition Request Ack the information that the UE context exists (and resources are reserved) for (in association with) Target MN1, which may be realized by including the ID of Target MN 1, or a flag / indication that Target SN1 is shared among multiple target MNs. o Target SN2 is prepared for the CHO of the UE, including e.g. reserving resources for the UE for the CHO and establishing a UE context (of the UE) for (in association with) Target MN2 o Target SN1 replies to Target MN 1 with SN Addition Request Ack upon completion of its preparation • Step 11: Target MN2 replies back to Source MN with HO Request Ack, which may comprise the information that the UE context exists (and resources are reserved) for (in association with) at Target SN1 also for Target MN1 and / or a list of prepared target SNs for Target MN2 • Steps 12-13: UE has handed over to a cell prepared by Target MN2 and Source MN is sending HO Cancel Request to Target MN1 o Source MN determines that Target MN1 has also prepared Target SN1 which is also prepared by Target MN2 and thus notifies Target MN1 accordingly o Source MN includes in Handover Cancel Request information that (resources reserved for the UE context at) Target SN1 should not be released • Step 14: Target MN1 determines that (resources reserved for the UE context at) Target SN1 should not be released • Steps 15-16: Target MN1 sends SN Release Request towards Target SN1 and Target SN2 o Target MN 1 sends UE Context Kept indicator in SN Release Request towards Target SN1 based on the information received by Source MN. It is to be noted that, while FIG. 12 shows an overall procedure for the sake of illustration, example embodiments may comprise only a subset of the illustrated functionalities for certain nodes, respectively. In this regard, reference is made to the methods or processes of FIGS. 7 to 11 and the description of example embodiments above. For instance, an example embodiment may comprise (corresponding functionality of) one or more of steps 6, 7 and / or 8 of / for a target secondary node, an example embodiment may comprise (corresponding functionality of) one or more of steps 6, 8 and / or 11 of / for a target master node, an example embodiment may comprise (corresponding functionality of) one or more of steps 5, 11, 12 and / or 13 of / for a source master node, an example embodiment may comprise (corresponding functionality of) one or more of steps 5, 13, 14 and / or 15 of / for a target master node. Also, an example embodiment may comprise (corresponding functionality of) one or more of step 8, a step corresponding to step 14 and / or a step corresponding to step 15 of / for a target master node. Further, example embodiments may comprise any combination of these example embodiments. FIG. 13 shows an example dual-connectivity conditional handover procedure according to at least one example embodiment. For this procedure, it is assumed that CHO of the UE does not take place but (before such CHO) Target MN1 is overloaded, as shown in step 14. As shown in FIG. 13, the example procedure may have the following steps: • Steps 1-2: Source MN prepares Target MN1 and Target MN2 for the Conditional Handover of the UE o Source MN sends Handover Request to both Target MN 1 and Target MN2 containing also CHO Request • Steps 3-4: Target MN1 prepares Target SN1 for the CHO of the UE o Target MN1 sends SN Addition Request to Target SN1 o Target SN1 is prepared for the CHO of the UE, including e.g. reserving resources for the UE for the CHO and establishing a UE context (of the UE) for (in association with) Target MN1 o Target SN1 replies to Target MN1 with SN Addition Request Ack upon completion of its preparation • Step 5: Target MN1 replies back to source MN with HO Request Ack, which may comprise a list of prepared target SNs for Target MN1 • Steps 6-10: Target MN2 prepares Target SN1 and Target SN2 for the CHO of the UE o Target MN2 sends SN Addition Request to Target SN1 and Target SN2 o Target SN 1 determines that there already exists the UE context (of the UE) for (in association with) Target MN1, i.e. there are already resources received for the UE for another target MN (i.e., Target MN 1) o Target SN1 provides in the responsive SN Addition Request Ack the information that the UE context exists (and resources are reserved) for (in association with) Target MN1, which may be realized by including the ID of Target MN1, or a flag / indication that Target SN1 is shared among multiple target MNs. o Target SN2 is prepared for the CHO of the UE, including e.g. reserving resources for the UE for the CHO and establishing a UE context (of the UE) for (in association with) Target MN2 o Target SN 1 replies to Target MN 1 with SN Addition Request Ack upon completion of its preparation • Step 11: Target MN2 replies back to Source MN with HO Request Ack, which may comprise the information that the UE context exists (and resources are reserved) for (in association with) at Target SN1 also for Target MN1 and / or a list of prepared target SNs for Target MN2 • Step 12: Source MN determines that Target MN 1 has also prepared Target SN1 which is also prepared by Target MN2 and thus notifies Target MN1 accordingly • Step 13: Source MN sends HO Cancel Request to Target MN 1 but with a specific cause code or indication that entails that Target MN1 should not perform cancellation, but the message is simply informative that Target SN1 is shared with another target MN • Step 14: Target MN1 determines to be overloaded, e.g. Target MN1 does not have available sufficient resources for the UE for the CHO, such that it is not ready for being selected in the CHO of the UE, and Target MN1 further determines that (resources reserved for the UE context at) Target SN1 should not be released • Step 15: Target MN1 sends CHO Cancel Request to Source MN to indicate that it is no longer prepared for the CHO of the UE • Steps 16-17: Target MN1 sends SN Release Request towards Target SN1 and Target SN2 o Target MN 1 sends UE Context Kept indicator in SN Release Request towards Target SN1 based on the information received by Source MN. While in the procedure of FIG. 13, HO Cancel Request with a specific cause code or indication is used in step 13, another message can also be used, as long as it (and / or its contents) indicates to the Target MN1 that that Target SN1 is shared with another target MN and / or (resources reserved for the UE context at) Target SN1 should not be released. It is to be noted that, while FIG. 13 shows an overall procedure for the sake of illustration, example embodiments may comprise only a subset of the illustrated functionalities for certain nodes, respectively. In this regard, reference is made to the methods or processes of FIGS. 7 to 11 and the description of example embodiments above. For instance, an example embodiment may comprise (corresponding functionality of) one or more of steps 6, 7 and / or 8 of / for a target secondary node, an example embodiment may comprise (corresponding functionality of) one or more of steps 6, 8 and / or 11 of / for a target master node, an example embodiment may comprise (corresponding functionality of) one or more of steps 5, 11, 12 and / or 13 of / for a source master node, an example embodiment may comprise (corresponding functionality of) one or more of steps 5, 13, 14, 15 and / or 16 of / for a target master node. Also, an example embodiment may comprise (corresponding functionality of) one or more of step 8, a step corresponding to step 14 and / or a step corresponding to step 16 of / for a target master node. Further, example embodiments may comprise any combination of these example embodiments. In any one of the procedures of FIGs. 12 and 13, Source MN determines that Target MN1 has also prepared Target SN1 such that Target SN1 is shared among multiple target MNs. Such determination may be accomplished in different ways using different information available at / for Source MN. As an example, when Source MN receives a list of prepared target SNs for Target MN1 in step 5 and a list of prepared target SNs for Target MN2 in step 11, Source MN may compare these lists to derive whether there is a target SN which is prepared by both Target MN1 and Target MN2. As another example, when Source MN receives information that the UE context exists (and resources are reserved) for (in association with) at Target SN1 also for Target MN1 in step 11, this information is sufficient and Source MN may make the determination based on this information. In any one of the procedures of FIGs. 12 and 13, it is assumed that Target MN1 shall no longer be prepared for the CHO of the UE, either due to a CHO decision by the UE for Target MN2 or overload scenario / condition of Target MN1. In such case, Target MN1 receives information for determining that (resources reserved for the UE context at) Target SN1 should not be released from Source MN. Yet, when Target MN2 shall no longer be prepared for the CHO of the UE, either due to a CHO decision by the UE for Target MN 1 or overload of Target MN2, no such information from Source MN is required. Rather, Target MN2 can determine that (resources reserved for the UE context at) Target SN1 should not be released by the information received in step 8. In the approach of FIGs. 12 and 13, once the target SN determines that it already contains a UE Context from another target MN (i.e. it has resources reserved for another target MN), it includes in SN Addition Request Ack of the second request a corresponding indication or information element (IE), such as e.g. the identification of the target MN for which it has already reserved resources for. Alternatively, instead of the target SN using the identification of the target MN for which it has already prepared resources for, it can use any other identification or a flag or indication indicating that the target SN is shared among multiple target MNs. A non-limiting example for such a flag may be that the flag is set to True if the target SN is shared among multiple target MNs and the flag is set to False if the target SN is not shared among multiple target MNSs. Additionally, the target MN that receives SN Addition Request Ack message should forward this information to the source MN. Additionally, each target MN can forward to the source MN in Handover Request Ack message a list of prepared target SNs. Source MN would now possess this information that it can utilize in case of handover cancel or overload situation / case / scenario to inform the respective target MN(s) about this occurrence if needed to avoid the release of the target SN (i.e. release of the UE context at the target SN) that might be used by other target MN(s). When the source MN prepares target MN(s) for CHO for the UE, the target MN(s) informs the source MN about the prepared target SN(s) (in all scenarios where target SN(s) is prepared, not only for CHO with CP AC). The source MN may then create a map, list or set of target SNs prepared by candidate MNs and, when it intends to cancel prepared CHO at a target MN that shares a target SN with another candidate target MN, the source MN can include a flag or other indication in the HO Cancel Request to let the candidate target MN know that it shall not release all UE context in the prepared target SN. In case of CHO with CP AC, the information could also provide the ID of the target PSCell(s) or target SN(s), so that the candidate target MN knows which prepared target SNs can be fully released, and which partially. For the scenarios where any of the prepared target MNs is overloaded, it can be avoided that the target MN contacts the source MN by sending the Conditional Handover Cancel Request and it may be too late to recover from the release of the target SN (i.e. release of the UE context at the target SN). Based on the information received, the source MN determines that the target MN contains any prepared target SN that should not be released, even prior to the target MN becoming overloaded, then the source MN should indicate this information to target MN either using Handover Cancel Request by adding a new cause that should avoid the release of the SN (include UE Context Kept Indicator IE) or by means of another message such as for instance CHO modification command. FIG. 14 shows an example dual-connectivity conditional handover procedure according to at least one example embodiment. For this procedure, it is assumed that CHO of the UE takes place between steps 12 and 13 or between steps 13 and 14, and Target MN2 is selected (as target node) for the UE. As shown in FIG. 14, the example procedure may have the following steps: • Steps 1-2: Source MN prepares Target MN1 and Target MN2 for the Conditional Handover of the UE o Source MN sends Handover Request to both Target MN 1 and Target MN2 containing also CHO Request • Steps 3-4: Target MN1 prepares Target SN1 for the CHO of the UE o Target MN1 sends SN Addition Request to Target SN1 o Target SN1 is prepared for the CHO of the UE, including e.g. reserving resources for the UE for the CHO and establishing a UE context (of the UE) for (in association with) Target MN1 o Target SN1 replies to Target MN1 with SN Addition Request Ack upon completion of its preparation • Step 5: Target MN 1 replies back to source MN with HO Request Ack • Steps 6-11: Target MN2 prepares Target SN1 and Target SN2 for the CHO of the UE o Target MN2 sends SN Addition Request to Target SN1 and Target SN2 o Target SN1 determines that there already exists the UE context (of the UE) for (in association with) Target MN1, i.e. there are already resources received for the UE for another target MN (i.e., Target MN 1) o Target SN1 provides in the responsive SN Addition Request Ack to Target MN2 the information that the UE context exists (and resources are reserved) for (in association with) Target MN1, which may be realized by including the ID of Target MN1, or a flag / indication that Target SN1 is shared among multiple target MNs. o Target SN1 provides in SN Modification Required to Target MN1 the information that the UE context exists (and resources are reserved) for (in association with) Target MN2, which may be realized by including the ID of Target MN2, or a flag / indication that Target SN1 is shared among multiple target MNs o Target SN2 is prepared for the CHO of the UE, including e.g. reserving resources for the UE for the CHO and establishing a UE context (of the UE) for (in association with) Target MN2 o Target SN1 replies to Target MN1 with SN Addition Request Ack upon completion of its preparation • Step 12: Target MN2 replies back to Source MN with HO Request Ack • Step 13: UE has handed over to a cell prepared by Target MN2 and Source MN is sending HO Cancel Request to Target MN1 • Step 14: Target MN1 determines that (resources reserved for the UE context at) Target SN1 should not be released, based on the information received in step 9 • Steps 15-16: Target MN1 sends SN Release Request towards Target SN1 and Target SN2 o Target MN1 sends UE Context Kept indicator in SN Release Request towards Target SN1 based on the information received by Target SN1 in step 9 in SN Modification Required. It is to be noted that, while FIG. 14 shows an overall procedure for the sake of illustration, example embodiments may comprise only a subset of the illustrated functionalities for certain nodes, respectively. In this regard, reference is made to the methods or processes of FIGS. 7 to 11 and the description of example embodiments above. For instance, an example embodiment may comprise (corresponding functionality of) one or more of steps 6, 7, 8 and / or 9 of / for a target secondary node, an example embodiment may comprise (corresponding functionality of) one or more of steps 6 and / or 8 of / for a target master node, an example embodiment may comprise (corresponding functionality of) one or more of steps 5, 12 and / or 13 of / for a source master node, an example embodiment may comprise (corresponding functionality of) one or more of steps 5, 9, 13, 14 and / or 15 of / for a target master node. Also, an example embodiment may comprise (corresponding functionality of) one or more of step 8, a step corresponding to step 13, a step corresponding to step 14 and / or a step corresponding to step 15 of / for a target master node. Further, example embodiments may comprise any combination of these example embodiments. FIG. 15 shows an example dual-connectivity conditional handover procedure according to at least one example embodiment. For this procedure, it is assumed that CHO of the UE does not take place but (before such CHO) Target MN1 is overloaded, as shown in step 13. As shown in FIG. 15, the example procedure may have the following steps: • Steps 1-2: Source MN prepares Target MN 1 and Target MN2 for the Conditional Handover of the UE o Source MN sends Handover Request to both Target MN 1 and Target MN2 containing also CHO Request • Steps 3-4: Target MN1 prepares Target SN1 for the CHO of the UE o Target MN1 sends SN Addition Request to Target SN1 o Target SN1 is prepared for the CHO of the UE, including e.g. reserving resources for the UE for the CHO and establishing a UE context (of the UE) for (in association with) Target MN1 o Target SN 1 replies to Target MN 1 with SN Addition Request Ack upon completion of its preparation • Step 5: Target MN 1 replies back to source MN with HO Request Ack • Steps 6-11: Target MN2 prepares Target SN1 and Target SN2 for the CHO of the UE o Target MN2 sends SN Addition Request to Target SN1 and Target SN2 o Target SN 1 determines that there already exists the UE context (of the UE) for (in association with) Target MN1, i.e. there are already resources received for the UE for another target MN (i.e., Target MN1) o Target SN1 provides in the responsive SN Addition Request Ack to Target MN2 the information that the UE context exists (and resources are reserved) for (in association with) Target MN1, which may be realized by including the ID of Target MN1, or a flag / indication that Target SN1 is shared among multiple target MNs. o Target SN1 provides in SN Modification Required to Target MN 1 the information that the UE context exists (and resources are reserved) for (in association with) Target MN2, which may be realized by including the ID of Target MN2, or a flag / indication that Target SN1 is shared among multiple target MNs o Target SN2 is prepared for the CHO of the UE, including e.g. reserving resources for the UE for the CHO and establishing a UE context (of the UE) for (in association with) Target MN2 o Target SN1 replies to Target MN 1 with SN Addition Request Ack upon completion of its preparation • Step 12: Target MN2 replies back to Source MN with HO Request Ack • Step 13: Target MN1 determines to be overloaded, e.g. Target MN1 does not have available sufficient resources for the UE for the CHO, such that it is not ready for being selected in the CHO of the UE, and Target MN1 further determines that (resources reserved for the UE context at) Target SN1 should not be released, based on the information received in step 9 • Step 14: Target MN1 sends CHO Cancel Request to Source MN to indicate that it is no longer prepared for the CHO of the UE • Steps 15-16: Target MN1 sends SN Release Request towards Target SN1 and Target SN2 o Target MN1 sends UE (Context Kept indicator in SN Release Request towards Target SN1 based on the information received by Target SN1 in step 9 in SN Modification Required. It is to be noted that, while FIG. 15 shows an overall procedure for the sake of illustration, example embodiments may comprise only a subset of the illustrated functionalities for certain nodes, respectively. In this regard, reference is made to the methods or processes of FIGS. 7 to 11 and the description of example embodiments above. For instance, an example embodiment may comprise (corresponding functionality of) one or more of steps 6, 7, 8 and / or 9 of / for a target secondary node, an example embodiment may comprise (corresponding functionality of) one or more of steps 6 and / or 8 of / for a target master node, an example embodiment may comprise (corresponding functionality of) one or more of steps 5, 12 and / or 14 of / for a source master node, an example embodiment may comprise (corresponding functionality of) one or more of steps 5, 9, 13, 14 and / or 15 of / for a target master node. Also, an example embodiment may comprise (corresponding functionality of) one or more of step 8, a step corresponding to step 13, a step corresponding to step 14 and / or a step corresponding to step 15 of / for a target master node. Further, example embodiments may comprise any combination of these example embodiments. In any one of the procedures of FIGs. 14 and 15, it is assumed that Target MN1 shall no longer be prepared for the CHO of the UE, either due to a CHO decision by the UE for Target MN2 or overload scenario / condition of Target MN1. In such case, Target MN1 can determine that (resources reserved for the UE context at) Target SN1 should not be released by the information received in step 9. When Target MN2 shall no longer be prepared for the CHO of the UE, either due to a CHO decision by the UE for Target MN1 or overload of Target MN2, no such information from Source MN is required. Rather, Target MN2 can determine that (resources reserved for the UE context at) Target SN1 should not be released by the information received in step 8. In the approach of FIGs. 14 and 15, compared to the approach of FIGs. 12 and 13, the target SN, once it determines that it has already prepared resources and possesses UE context for another target MN, it sends an SN modification required message towards that target MN to notify the target MN that there is another target MN that has reserved the target SN as well. In that case, the target MN would not release the target SN (i.e. release the UE context at the target SN) in case of overload scenario / condition. Alternatively, instead of the target SN indicating the exact ID of the target MN for which it has prepared resources for to the other target MN(s), it can simply indicate with a flag or indication that the target SN is shared. When the target SN determines that all other target MN(s) apart for one have been released it can notify via SN modification required the last Target MN that the target SN is no longer shared and the target MN should not include the UE Context Kept indicator when issuing SN Release Request. This is described in further detail with reference to FIG. 16 below. FIG. 16 shows an example dual-connectivity conditional handover procedure according to at least one example embodiment. For this procedure, it is assumed that CHO of the UE takes place in or before step 8 and Target MN2 is selected (as target node) for the UE, or CHO of the UE does not take place but (before such CHO) Target MN1 is overloaded, as shown in step 8. The example procedure may have the steps 1 to 8. For steps 1 to 8, reference is made to any one of the procedures of FIGs. 12 to 15. Specifically, steps 1 to 8 in the procedure of FIG. 16 may correspond to steps 1 to 14 in the procedure of FIG. 12, steps 1 to 15 in the procedure of FIG. 13, steps 1 to 14 in the procedure of FIG. 14, or steps 1 to 14 in the procedure of FIG. 15. When in step 7, it is described that both Target MN1 and Target MN2 are informed that Target SN1 is shared, this encompasses a direct information from Target SN1 (such as e.g. in step 8 of FIG. 12 or 13 for Target MN2, or in steps 8 and 9 of FIG. 14 or 15 for both Target MN1 and Target MN2) or an indirect information via Source MN (such as e.g. in steps 8-13 of FIG. 12 or 13 for Target MN1). As shown in FIG. 16, irrespective of the details / specifics of the preceding steps (i.e. which one of the corresponding steps procedures of FIGs. 12 to 15 apply), the example procedure may have the following further steps: • Steps 9-10: Target MN1 sends SN Release Request towards Target SN1 and Target SN2 o Target MN1 sends UE Context Kept indicator in SN Release Request towards Target SN1 based on the information received by Source MN. • Step 11: Target SN1 determines that only Target MN2 is using Target SN1 (due to release by Target MN1) • Step 12. Target SN1 inform Target MN2 accordingly by SN Modification Required including the information that Target SN1 is no longer shared • Step 13: Target MN2 determines, based on the information received in step 12, that (resources reserved for the UE context at) Target SN1 should be released when SN Release is to be issued the next time, i.e. SN Release Request is to be sent without UE Context Kept indicator. It is to be noted that, while FIG. 16 shows an overall procedure for the sake of illustration, example embodiments may comprise only a subset of the illustrated functionalities for certain nodes, respectively. In this regard, reference is made to the methods or processes of FIGS. 7 to 11 and the description of example embodiments above. For instance, an example embodiment may comprise (corresponding functionality of) one or more of steps 6, 7, 9, 11 and / or 12 of / for a target secondary node, an example embodiment may comprise (corresponding functionality of) one or more of steps 5, 7, 8 and / or 9 of / for a target master node, an example embodiment may comprise (corresponding functionality of) one or more of steps 5 and / or 8 of / for a source master node, an example embodiment may comprise (corresponding functionality of) one or more of steps 6, 7, 12 and / or 13 of / for a target master node. Further, example embodiments may comprise any combination of these example embodiments. In the approach of FIG. 16, when the target SN determines that all other target MN(s) apart from one (remaining) target MN have been released, it notifies e.g. via SN Modification Required, the remaining target MN that the target SN is no longer shared and the remaining target MN should not include the UE Context Kept indicator when issuing SN Release Request. This can occur for both scenarios of handover cancel and overload. In any one of the procedures of FIGs. 12 to 16, a flag / indication that Target SN1 is shared among multiple target MNs may be sent from Target SN1 to Target MN1 and / or Target MN2 (see step 8 in FIGs. 12 and 13, steps 8 and 9 in FIGs. 14 and 15, step 7 in FIG. 16). This may be realized by a dedicated flag or information element, which may be referred to as UE Context for CHO IE, being set to "shared". Namely, such flag or information element may be of enumerated type with the values “shared” and “not shared”, while only one of these values may be used in a respective message. FIG. 17 shows an example dual-connectivity conditional handover procedure according to at least one example embodiment. For this procedure, it is assumed that CHO of the UE takes place between steps 10 and 11 and Target MN2 is selected (as target node) for the UE, or CHO of the UE does not take place but (before such CHO) Target MN1 is overloaded, as shown in step 11. As shown in FIG. 17, the example procedure may have the following steps: • Steps 1-2: Source MN prepares Target MN 1 and Target MN2 for the Conditional Handover of the UE o Source MN sends Handover Request to both Target MN 1 and Target MN2 containing also CHO Request • Steps 3-4: Target MN1 prepares Target SN1 for the CHO of the UE o Target MN1 sends SN Addition Request to Target SN1 o Target SN1 is prepared for the CHO of the UE, including e.g. reserving resources for the UE for the CHO and establishing a UE context (of the UE) for (in association with) Target MN1 o Target SN1 replies to Target MN 1 with SN Addition Request Ack upon completion of its preparation • Step 5: Target MN 1 replies back to source MN with HO Request Ack • Steps 6-7: Target MN2 prepares Target SN1 for the CHO of the UE o Target MN2 sends SN Addition Request to Target SN1 o Target SN1 is prepared for the CHO of the UE, including e.g. reserving resources for the UE for the CHO and establishing a UE context (of the UE) for (in association with) Target MN2 o Target SN1 replies to Target MN2 with SN Addition Request Ack upon completion of its preparation • Steps 8-9: Target MN2 prepares Target SN2 for the CHO of the UE o Target MN2 sends SN Addition Request to Target SN2 o Target SN2 is prepared for the CHO of the UE, including e.g. reserving resources for the UE for the CHO and establishing a UE context (of the UE) for (in association with) Target MN2 o Target SN2 replies to Target MN2 with SN Addition Request Ack upon completion of its preparation • Step 10: Target MN2 replies back to source MN with HO Request Ack • Step 11: Target MN1 receives HO Cancel Request or determines to be overloaded • Steps 12-13: Target MN1 sends SN Release Request towards Target SN1 and Target SN2 • Step 14: Target SN1 determines that Target SN1 is shared by Target MN1 and Target MN2 (similar to the determination is step 7 of any one of FIGs. 12 to 15), thus determines that Target SN1 should not be released (for Target MN2), and does not release Target SN1 It is to be noted that, while FIG. 17 shows an overall procedure for the sake of illustration, example embodiments may comprise only a subset of the illustrated functionalities for certain nodes, respectively. In this regard, reference is made to the methods or processes of FIGS. 7 to 11 and the description of example embodiments above. For instance, an example embodiment may comprise (corresponding functionality of) one or more of steps 6, 7, 12 and / or 14 of / for a target secondary node, an example embodiment may comprise (corresponding functionality of) one or more of steps 6, 7 and / or 10 of / for a target master node, an example embodiment may comprise (corresponding functionality of) one or more of steps 5, 10 and / or 11 of / for a source master node, an example embodiment may comprise (corresponding functionality of) one or more of steps 5, 11 and / or 12 of / for a target master node. Further, example embodiments may comprise any combination of these example embodiments. In the approach of FIG. 17, the target SN keeps track of all target MNs for which it has prepared resources for, i.e. it has the UE context for (in association with) these target MNs. In case that one or more target MNs request to release the target SN, the target SN has to determine if there are more target MNs for which it has prepared resources for regarding a particular UE and thus should not be released for the other target MNs. In this way, the above issues mentioned are solved directly at target SN without need for further changes in signaling and / or at other nodes. It is to be noted that any message names, parameter names, or the like, as used in the description of any one of the procedures of FIGs. 12 to 117 are only exemplary and / or illustrative, while messages, parameters, or the like with different names but similar meaning, purpose, function, etc. are equally applicable. The procedures of FIGs. 12 to 17, or parts thereof, may be arbitrarily combined, as far as conceivable or practicable. Example embodiments comprise any conceivable and / or practicable combination of any one of the methods or presses of FIGs. 7 to 11, or parts thereof, the procedures of FIGs. 12 to 17, or parts thereof, and / or the example embodiments described above. As described above, example embodiments are capable of enabling (or otherwise facilitating or realizing) conditional handover with target secondary node, such as e.g. conditional handover of / for a user equipment configured with dual connectivity using master and secondary nodes. At least certain example embodiments are effective not only for 3GPP Release 18 but also for 3GPP Release 17. At least certain example embodiments are effective in / for both handover cancel and overload situations / cases / scenarios, i.e. as sort of reactive concept (due to CHO being performed) or sort of proactive concept (without / before CHO being performed). At least certain example are efficient (and backward-compatible) in that they mainly reuse existing mechanisms and messages, thus avoiding the need for any new signaling and / or processes, and / or avoiding further signaling overhead. The above-described functionality as well as its related operations, procedures, methods and processes may be implemented by respective functional elements, entities, modules, units, processors, or the like, as described below. These functional elements, entities, modules, units, processors, or the like, e.g., the implementation of one or more example embodiments, may be realized in a cloud environment, by SDN, by NFV / NFVI, or the like. While various example embodiments are described with reference to operations, procedures, methods and processes, these example embodiments also cover respective apparatuses, entities, modules, units, network nodes and / or systems, including software and / or hardware thereof. Respective example embodiments are described below, while for the sake of brevity reference is made to the detailed description of respective corresponding configurations / setups, schemes, structures, processes, sequences, methods as well as functionalities, principles and operations according to FIGS. 4 to 17. FIG. 18 shows a schematic block diagram illustrating a structure of apparatuses according to at least one example embodiment. In FIG. 18, the blocks are basically configured to perform respective methods, procedures and / or functions as described above. It is to be noted that the individual blocks are meant to illustrate respective functional blocks implementing a respective function, process or procedure, respectively. Such functional blocks are implementation-independent, e.g. may be implemented by means of any kind of hardware or software or combination thereof, respectively. According to at least one example embodiment, an apparatus 1810 according to at least one example embodiment may represent or realize / implement / embody a (e.g., part of a) target secondary node. Hence, the apparatus 1810 may be configured to perform a procedure and / or exhibit a functionality and / or implement a mechanism, as described above for a target secondary node. Such apparatus may be illustrated or realized as is shown in FIG. 3. The apparatus or its at least one processor 320 (e.g., together with instructions stored in its at least one memory 330) may be configured to receive, from a second target master node, a secondary-node addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with the second target master node, determine that the target secondary node is already prepared for the conditional handover of the user equipment by identifying that the user equipment context exists in association with a first target master node, and transmit, to at least one of the first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. As illustrated in FIG. 18, the apparatus 1810 may comprise (at least) one or more unit / means / circuitry, denoted by receiving section 1811, which represent any implementation for (or configured to) receive (receiving), from a second target master node, a secondary-node addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with the second target master node, one or more unit / means / circuitry, denoted by determining section 1812, which represent any implementation for (or configured to) determining (determine) that the target secondary node is already prepared for the conditional handover of the user equipment by identifying that the user equipment context exists in association with a first target master node, and one or more unit / means / circuitry, denoted by transmitting section 1813, which represent any implementation for (or configured to) transmitting (transmit), to at least one of the first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. The apparatus or corresponding unit / means / circuitry may be adapted, configured or operable to perform or carry out any one of the methods, steps and / or operations, as described above for a target secondary node. According to at least one example embodiment, an apparatus 1820 according to at least one example embodiment may represent or realize / implement / embody a (e.g., part of a) target master node. Hence, the apparatus 1820 may be configured to perform a procedure and / or exhibit a functionality and / or implement a mechanism, as described above for a target master node. Such apparatus may be illustrated or realized as is shown in FIG. 3. The apparatus or its at least one processor 320 (e.g., together with instructions stored in its at least one memory 330) may be configured to transmit, to a target secondary node, a secondary-node addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with the target master node, receive information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node, and determine, based on said information, that the user equipment context is to be kept when the target secondary node is to be released from the preparation for the conditional handover of the user equipment for the target master node. As illustrated in FIG. 18, the apparatus 1820 may comprise (at least) one or more unit / means / circuitry, denoted by transmitting section 1821, which represent any implementation for (or configured to) transmit (transmitting), to a target secondary node, a secondary-node addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with the target master node, one or more unit / means / circuitry, denoted by receiving section 1822, which represent any implementation for (or configured to) receive (receiving), information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node, and one or more unit / means / circuitry, denoted by determining section 1823, which represent any implementation for (or configured to) determine (determining), based on said information, that the user equipment context is to be kept when the target secondary node is to be released from the preparation for the conditional handover of the user equipment for the target master node. The apparatus or corresponding unit / means / circuitry may be adapted, configured or operable to perform or carry out any one of the methods, steps and / or operations, as described above for a target master node. According to at least one example embodiment, an apparatus 1830 according to at least one example embodiment may represent or realize / implement / embody a (e.g., part of a) source master node. Hence, the apparatus 1830 may be configured to perform a procedure and / or exhibit a functionality and / or implement a mechanism, as described above for a source master node. Such apparatus may be illustrated or realized as is shown in FIG. 3. The apparatus or its at least one processor 320 (e.g., together with instructions stored in its at least one memory 330) may be configured to receive, from a second target master node, a handover request acknowledgment message comprising information regarding preparation of a target secondary node for a conditional handover of a user equipment, determine that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node, and transmit, to at least one of a first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. As illustrated in FIG. 18, the apparatus 1830 may comprise (at least) one or more unit / means / circuitry, denoted by receiving section 1831, which represent any implementation for (or configured to) receive (receiving), from a second target master node, a handover request acknowledgment message comprising information regarding preparation of a target secondary node for a conditional handover of a user equipment, one or more unit / means / circuitry, denoted by determining section 1832, which represent any implementation for (or configured to) determine (determining) that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node, and one or more unit / means / circuitry, denoted by transmitting section 1833, which represent any implementation for (or configured to) transmit (transmitting), to at least one of a first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. The apparatus or corresponding unit / means / circuitry may be adapted, configured or operable to perform or carry out any one of the methods, steps and / or operations, as described above for a source master node. For further details regarding the operability / functionality of the apparatuses (or units / means thereof) according to some example embodiments, reference is made to the above description in connection with any one of FIGS. 1 to 17, respectively. According to some example embodiments, any one of the (at least one) processor, the (at least one) memory and the (at least one) interface, as well as any one of the illustrated units / means, may be implemented as individual modules, chips, chipsets, circuitries or the like, or one or more of them can be implemented as a common module, chip, chipset, circuitry or the like, respectively. As used herein, the term “circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry) and (b) combinations of hardware circuits and software, such as (as applicable): (i) a combination of analog and / or digital hardware circuit(s) with software / firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions), and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation. This definition of circuitry applies to all uses of this term herein, including in any claims. As a further example, as used herein, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device. According to some example embodiments, a system may comprise any conceivable combination of any depicted or described apparatuses and other network elements or functional entities, which are configured to cooperate as described above. In general, it is to be noted that respective functional blocks or elements according to various embodiments described herein can be implemented by any known means, either in hardware and / or software, respectively, if it is only adapted to perform the described functions of the respective parts. The mentioned method steps can be realized in individual functional blocks or by individual devices, or one or more of the method steps can be realized in a single functional block or by a single device. Generally, a basic system architecture of a (tele)communication network including a mobile communication system where some examples of example embodiments are applicable may include an architecture of one or more communication networks including wireless access network sub- / system(s) and possibly core network(s). Such an architecture may include one or more communication network control elements or functions, such as e.g. access network elements, radio access network elements, access service network gateways or base transceiver stations, like a base station, an access point, a NodeB (NB), an eNB or a gNB, a distributed or a centralized unit, which controls a respective coverage area or cell(s) and with which one or more communication stations such as communication elements or functions, like user devices or terminal devices, like a UE, or another device having a similar function, such as a modem chipset, a chip, a module, and so forth, which can also be part of a station, an element, a function or an application capable of conducting a communication, such as a UE, an element or function usable in a machine-to-machine communication architecture, or attached as a separate element to such an element, function or application capable of conducting a communication, or the like, are capable to communicate via one or more channels via one or more communication beams for transmitting several types of data in a plurality of access domains. Furthermore, core network elements or network functions, such as gateway network elements / functions, mobility management entities, a mobile switching center, servers, databases and the like may be included. The general functions and interconnections of the described elements and functions, which also depend on the actual network type, are known to those skilled in the art and described in corresponding specifications, so that a detailed description thereof is omitted herein. It should be appreciated that several additional network elements and signaling links may be employed for a communication to or from an element, function or application, like a communication endpoint, a communication network control element, such as a server, a gateway, a radio network controller, and other elements of the same or other communication networks besides those described in detail herein below. A communication network architecture as being considered in examples of example embodiments may also be able to communicate with other networks, such as a public switched telephone network or the Internet, including the Intemet-of-Things. The communication network may also be able to support the usage of cloud services for virtual network elements or functions thereof, wherein it is to be noted that the virtual network part of the (tele)communication network can also be provided by non-cloud resources, e.g. an internal network or the like. It should be appreciated that network elements of an access system, of a core network, and so forth, and / or respective functionalities may be implemented by using any node, host, server, access node or entity, and so forth being suitable for such a usage. Generally, a network function can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g. a cloud infrastructure. Any method step is suitable to be implemented as software or by hardware without changing the idea or scope of the various example embodiments. Such software may be software code independent and can be specified using any known or future developed programming language, such as e.g. Java, C++, C, and Assembler, as long as the functionality defined by the method steps is preserved. Such hardware may be hardware type independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor-Transistor Logic), and so forth, using for example ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field-programmable Gate Arrays) components, CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components. A device / apparatus may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of a device / apparatus or module, instead of being hardware implemented, be implemented as software in a (software) module, such as a computer program or a computer program product comprising executable software code portions for execution / being run on a processor. A device may be regarded as a device / apparatus or as an assembly of more than one device / apparatus, whether functionally in cooperation with each other or functionally independently of each other but in a same device housing, for example. Apparatuses and / or units / means or parts thereof can be implemented as individual devices, but this does not exclude that they may be implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved. Such and similar principles are to be considered as known to a skilled person. Software in the sense of the description comprises software code as such comprising code means or portions or a computer program or a computer program product for performing the respective functions, as well as software (or a computer program or a computer program product) embodied on a tangible medium, such as a computer-readable (storage) medium having stored thereon a respective data structure or code means / portions or embodied in a signal or in a chip, potentially during processing thereof. Various example embodiments also cover any conceivable combination of method steps and operations described above, and any conceivable combination of nodes, apparatuses, modules or elements described above, as long as the above-described concepts of methodology and structural arrangement are applicable. In view of the above, there are provided measures for (e.g. enabling / facilitating / realizing) conditional handover with target secondary node. Such measures may, for example, comprise that a target secondary node in a conditional handover scenario, in which at least a first target master node and a second target master node are prepared for conditional handover of a user equipment, receives, from the second target master node, a secondary-node addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with the second target master node, determines that the target secondary node is already prepared for the conditional handover of the user equipment by identifying that the user equipment context exists in association with a first target master node, and transmits, to at least one of the first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. Some aspects comprise: Aspect 39. A method, comprising: receiving, from a second target master node, a secondary-node addition request message for preparing a target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with the second target master node, determining that the target secondary node is already prepared for the conditional handover of the user equipment by identifying that the user equipment context exists in association with a first target master node, and transmitting, to at least one of the first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. Aspect 40. The method according to aspect 39, comprising: transmitting, to the second target master node, a secondary-node addition request acknowledgment message comprising said information. Aspect 41. The method according to aspect 40, wherein said information comprises: an information that the user equipment context also exists in association with the first target master node, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes. Aspect 42. The method according to aspect 39, comprising: transmitting, from the target secondary node to the second target master node, a secondarynode addition request acknowledgment message comprising said information, and transmitting, to the first target master node, a secondary-node modification request message comprising said information. Aspect 43. The method according to aspect 42, wherein said information in the secondary-node addition request acknowledgment message comprises: an information that the user equipment context also exists in association with the first target master node, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes, and / or said information in the secondary-node modification request message comprises: an information that the user equipment context also exists in association with the second target master node, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes. Aspect 44. The method according to any one of aspects 39 to 43, comprising: receiving, from one of the first target master node and the second target master node, a secondary-node release request message comprising an indication that the user equipment context is to be kept, determining that the target secondary node remains prepared only for the conditional handover with regard to the user equipment context in association with the other one of the first target master node and the second target master node, and transmitting, to the other one of the first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover only for the other one of the first target master node and the second target master node. Aspect 45. The method according to aspect 44, comprising: transmitting, to the other one of the first target master node and the second target master node, a secondary-node modification request message comprising said information. Aspect 46. The method according to aspect 45, wherein said information comprises: an information that the user equipment context exists only in association with the other one of the first target master node and the second target master node, or a flag or indication indicating that the target secondary node is not shared among multiple target master nodes. Aspect 47. The method according to any one of aspects 44 to 46, wherein the secondary-node release request message comprising the indication that the user equipment context is to be kept is triggered by the one of the first target master node and the second target master node in response to the preparation for the conditional handover being cancelled or in response to being overloaded. Aspect 48. The method according to any one of aspects 39 to 47, wherein the first and second target master nodes and the target secondary node are configured to provide dual or multiple connectivity for the user equipment. Aspect 49. A method, comprising: transmitting, to a target secondary node, a secondary-node addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with a target master node, receiving information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node, and determining, based on said information, that the user equipment context is to be kept when the target secondary node is to be released from the preparation for the conditional handover of the user equipment for the target master node. Aspect 50. The method according to aspect 49, comprising: receiving, from a source master node, a handover cancel request message comprising said information. Aspect 51. The method according to aspect 50, comprising: transmitting, to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept. Aspect 52. The method according to aspect 49, comprising: receive, by the target master node from the source master node, a message comprising said information. Aspect 53. The method according to aspect 52, wherein the message is a handover cancel request message further comprising a cause code or indication indicating that the message does not request handover cancellation and / or the message is to notify about said information. Aspect 54. The method according to aspect 52 or 53, comprising: determining that the target master node is overloaded, and transmitting, to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept. Aspect 55. The method according to any one of aspects 50 to 54, wherein said information comprises: an information that the user equipment context should not be released, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes. Aspect 56. The method according to any one of aspects 49 to 55, comprising: transmitting, to the source master node, a list or set of target secondary nodes being prepared for the conditional handover for the target master node. Aspect 57. The method according to aspect 49, comprising: receiving, from the target secondary node, a secondary-node addition request acknowledgment message comprising said information. Aspect 58. The method according to aspect 57, comprising: transmitting, to the source master node, a handover request acknowledgment message comprising said information or a list or set of target secondary nodes being prepared for the conditional handover for the target master node. Aspect 59. The method according to aspect 57 or 58, wherein said information comprises: an information that the user equipment context also exists for another target master node, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes. Aspect 60. The method according to any one of aspects 57 to 59, comprising: receiving, from the source master node, a handover cancel request message, and transmitting, to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept. Aspect 61. The method according to any one of aspects 57 to 59, comprising: determining that the target master node is overloaded, and transmitting, to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept. Aspect 62. The method according to aspect 49, comprising: receiving, from the target secondary node, a secondary-node addition request acknowledgment message comprising said information or a secondary-node modification request message comprising said information. Aspect 63. The method according to aspect 62, wherein said information comprises: an information that the user equipment context also exists for another target master node, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes. Aspect 64. The method according to aspect 62 or 63, comprising: receiving, from the source master node, a handover cancel request message, and transmitting, to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept. Aspect 65. The method according to aspect 62 or 63, comprising: determining that the target master node is overloaded, and transmitting, to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept. Aspect 66. The method according to any one of aspects 49 to 65, comprising: receiving, from the target secondary node, information indicating that the target secondary node is prepared for the conditional handover only for the target master node, and determining, based on said information, that the user equipment context is to be released when the target secondary node is to be released from the preparation for the conditional handover for the target master node. Aspect 67. The method according to aspect 66, comprising: receiving, from the target secondary node, a secondary-node modification request message comprising said information. Aspect 68. The method according to aspect 66 or 67, wherein said information comprises: an information that the user equipment context exists only for the target master node, or a flag or indication indicating that the target secondary node is not shared among multiple target master nodes. Aspect 69. The method according to any one of aspects 49 to 68, wherein the target and another master node and the target secondary node are configured to provide dual or multiple connectivity for the user equipment. Aspect 70. A method, comprising: receiving, from a second target master node, a handover request acknowledgment message comprising information regarding preparation of a target secondary node for a conditional handover of a user equipment, determining that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node, and transmitting, to at least one of a first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node. Aspect 71. The method according to aspect 70, wherein the information regarding preparation of a target secondary node for the conditional handover comprises a list or set of target secondary nodes being prepared for the conditional handover for the second master node, the method comprises receiving, from the first target master node, a list or set of target secondary nodes being prepared for the conditional handover for the first master node, and the method comprises determining that the target secondary node is prepared for the conditional handover for more than one target master node by comparing the lists or sets received from the first target master node and a second target master node. the information regarding preparation of a target secondary node for the conditional handover comprises: an information that a user equipment context, in association with which the target secondary node is prepared for the conditional handover, also exists in association with the first target master node, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes, and the method comprises determining that the target secondary node is prepared for the conditional handover for more than one target master node based on said information. Aspect 73. The method according to any one of aspects 70 to 72, comprising: determining that the first target master node is not selected as target for the conditional handover of the user equipment, and transmitting, to first target master node, a handover cancel request message comprising the information indicating that the target secondary node is prepared for the conditional handover for more than one target master node. Aspect 74. The method according to any one of aspects 70 to 72, comprising: transmitting, to first target master node, a message comprising the information indicating that the target secondary node is prepared for the conditional handover for more than one target master node. Aspect 75. The method according to aspect 74, wherein the message is a handover cancel request message further comprising a cause code or indication indicating that the message does not request handover cancellation and / or the message is to notify about said information. Aspect 76. The method according to any one of aspects 70 to 75, wherein the first and second target master nodes and the target secondary node are configured to provide dual or multiple connectivity for the user equipment. Aspect 77. A computer program product comprising computer program code which, when the computer program code is executed on a computer, is configured to cause the computer to carry out the method according to any one of aspects 39 to 48 or any one of aspects 49 to 69 or any one of aspects 70 to 76. Even though various example embodiments are described above with reference to the accompanying drawings, it is to be understood that the various example embodiments are not restricted thereto. Rather, it is apparent to those skilled in the art that the various example embodiments can be modified in many ways without departing from the intended scope.

Claims

1. An apparatus, comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to:receive, by a target secondary node from a second target master node, a secondarynode addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with the second target master node,determine, at the target secondary node, that the target secondary node is already prepared for the conditional handover of the user equipment by identifying that the user equipment context exists in association with a first target master node, andtransmit, from the target secondary node to at least one of the first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node.

2. The apparatus according to claim 1, wherein the instructions, when executed by the at least one processor, cause the apparatus to:transmit, from the target secondary node to the second target master node, a secondary-node addition request acknowledgment message comprising said information.

3. The apparatus according to claim 2, whereinsaid information comprises: an information that the user equipment context also exists in association with the first target master node, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes.

4. The apparatus according to claim 1, wherein the instructions, when executed by the at least one processor, cause the apparatus to:transmit, from the target secondary node to the second target master node, a secondary-node addition request acknowledgment message comprising said information, andtransmit, to the first target master node, a secondary-node modification request message comprising said information.said information in the secondary-node addition request acknowledgment message comprises: an information that the user equipment context also exists in association with the first target master node, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes, and / orsaid information in the secondary-node modification request message comprises: an information that the user equipment context also exists in association with the second target master node, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes.

6. The apparatus according to any one of claims 1 to 5, wherein the instructions, when executed by the at least one processor, cause the apparatus to:receive, at the target secondary node from one of the first target master node and the second target master node, a secondary-node release request message comprising an indication that the user equipment context is to be kept,determine, at the target secondary node, that the target secondary node remains prepared only for the conditional handover with regard to the user equipment context in association with the other one of the first target master node and the second target master node, andtransmit, from the target secondary node to the other one of the first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover only for the other one of the first target master node and the second target master node.

7. The apparatus according to claim 6, wherein the instructions, when executed by the at least one processor, cause the apparatus to:transmit, from the target secondary node to the other one of the first target master node and the second target master node, a secondary-node modification request message comprising said information.

8. The apparatus according to claim 7, whereinsaid information comprises: an information that the user equipment context exists only in association with the other one of the first target master node and the second target master node, or a flag or indication indicating that the target secondary node is not shared among multiple target master nodes.

9. The apparatus according to any one of claims 6 to 8, whereinthe secondary-node release request message comprising the indication that the user equipment context is to be kept is triggered by the one of the first target master node and the second target master node in response to the preparation for the conditional handover being cancelled or in response to being overloaded.

10. The apparatus according to any one of claims 1 to 9, whereinthe first and second target master nodes and the target secondary node are configured to provide dual or multiple connectivity for the user equipment.

11. An apparatus, comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to:transmit, from a target master node to a target secondary node, a secondary-node addition request message for preparing the target secondary node for a conditional handover of a user equipment by establishing a user equipment context in association with the target master node,receive, by the target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node, anddetermine, at the target master node, based on said information, that the user equipment context is to be kept when the target secondary node is to be released from the preparation for the conditional handover of the user equipment for the target master node.

12. The apparatus according to claim 11, wherein the instructions, when executed by the at least one processor, cause the apparatus to:receive, by the target master node from a source master node, a handover cancel request message comprising said information.

13. The apparatus according to claim 12, wherein the instructions, when executed by the at least one processor, cause the apparatus to:transmit, from the target master node to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept.

14. The apparatus according to claim 11, wherein the instructions, when executed by the at least one processor, cause the apparatus to:receive, by the target master node from the source master node, a message comprising said information.

15. The apparatus according to claim 14, whereinthe message is a handover cancel request message further comprising a cause code or indication indicating that the message does not request handover cancellation and / or the message is to notify about said information.

16. The apparatus according to claim 14 or 15, wherein the instructions, when executed by the at least one processor, cause the apparatus to:determine, at the target master node, that the target master node is overloaded, andtransmit, from the target master node to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept.

17. The apparatus according to any one of claims 11 to 16, whereinsaid information comprises: an information that the user equipment context should not be released, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes.

18. The apparatus according to any one of claims 11 to 17, wherein the instructions, when executed by the at least one processor, cause the apparatus to:transmit, from the target master node to the source master node, a list or set of target secondary nodes being prepared for the conditional handover for the target master node.

19. The apparatus according to claim 11, wherein the instructions, when executed by the at least one processor, cause the apparatus to:receive, by the target master node from the target secondary node, a secondary-node addition request acknowledgment message comprising said information.

20. The apparatus according to claim 19, wherein the instructions, when executed by the at least one processor, cause the apparatus to:transmit, from the target master node to the source master node, a handover request acknowledgment message comprising said information or a list or set of target secondary nodes being prepared for the conditional handover for the target master node.said information comprises: an information that the user equipment context also exists for another target master node, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes.

22. The apparatus according to any one of claims 19 to 21, wherein the instructions, when executed by the at least one processor, cause the apparatus to:receive, by the target master node from the source master node, a handover cancel request message, andtransmit, from the target master node to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept.

23. The apparatus according to any one of claims 19 to 21, wherein the instructions, when executed by the at least one processor, cause the apparatus to:determine, at the target master node, that the target master node is overloaded, andtransmit, from the target master node to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept.

24. The apparatus according to claim 11, wherein the instructions, when executed by the at least one processor, cause the apparatus to:receive, by the target master node from the target secondary node, a secondary-node addition request acknowledgment message comprising said information or a secondary-node modification request message comprising said information.

25. The apparatus according to claim 24, whereinsaid information comprises: an information that the user equipment context also exists for another target master node, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes.

26. The apparatus according to claim 24 or 25, wherein the instructions, when executed by the at least one processor, cause the apparatus to:receive, by the target master node from the source master node, a handover cancel request message, andtransmit, from the target master node to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept.

27. The apparatus according to claim 24 or 25, wherein the instructions, when executed by the at least one processor, cause the apparatus to:determine, at the target master node, that the target master node is overloaded, andtransmit, from the target master node to the target secondary node, a secondary-node release request message comprising an indication that the user equipment context is to be kept.

28. The apparatus according to any one of claims 11 to 27, wherein the instructions, when executed by the at least one processor, cause the apparatus to:receive, at the target master node from the target secondary node, information indicating that the target secondary node is prepared for the conditional handover only for the target master node, anddetermine, at the target master node, based on said information, that the user equipment context is to be released when the target secondary node is to be released from the preparation for the conditional handover for the target master node.

29. The apparatus according to claim 28, wherein the instructions, when executed by the at least one processor, cause the apparatus to:receive, by the target master node from the target secondary node, a secondary-node modification request message comprising said information.

30. The apparatus according to claim 28 or 29, whereinsaid information comprises: an information that the user equipment context exists only for the target master node, or a flag or indication indicating that the target secondary node is not shared among multiple target master nodes.

31. The apparatus according to any one of claims 11 to 30, whereinthe target and another master node and the target secondary node are configured to provide dual or multiple connectivity for the user equipment.

32. An apparatus, comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to:receive, by a source master node from a second target master node, a handover request acknowledgment message comprising information regarding preparation of a target secondary node for a conditional handover of a user equipment,determine, at the source master node, that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node, andtransmit, from the source master node to at least one of a first target master node and the second target master node, information indicating that the target secondary node is prepared for the conditional handover of the user equipment for more than one target master node.

33. The apparatus according to claim 32, whereinthe information regarding preparation of a target secondary node for the conditional handover comprises a list or set of target secondary nodes being prepared for the conditional handover for the second master node,the apparatus is further configured to receive, at the source master node from the first target master node, a list or set of target secondary nodes being prepared for the conditional handover for the first master node, andthe apparatus is configured to determine, at the source master node, that the target secondary node is prepared for the conditional handover for more than one target master node by comparing the lists or sets received from the first target master node and a second target master node.

34. The apparatus according to claim 32, whereinthe information regarding preparation of a target secondary node for the conditional handover comprises: an information that a user equipment context, in association with which the target secondary node is prepared for the conditional handover, also exists in association with the first target master node, or a flag or indication indicating that the target secondary node is shared among multiple target master nodes, andthe apparatus is configured to determine, at the source master node, that the target secondary node is prepared for the conditional handover for more than one target master node based on said information.

35. The apparatus according to any one of claims 32 to 34, wherein the instructions, when executed by the at least one processor, cause the apparatus to:determine, at the source master node, that the first target master node is not selected as target for the conditional handover of the user equipment, andtransmit, from the source master node to first target master node, a handover cancel request message comprising the information indicating that the target secondary node is prepared for the conditional handover for more than one target master node.5 36. The apparatus according to any one of claims 32 to 34, wherein the instructions, whenexecuted by the at least one processor, cause the apparatus to:transmit, from the source master node to first target master node, a message comprising the information indicating that the target secondary node is prepared for the conditional handover for more than one target master node.1037. The apparatus according to claim 36, whereinthe message is a handover cancel request message further comprising a cause code or indication indicating that the message does not request handover cancellation and / or the message is to notify about said information.1538. The apparatus according to any one of claims 32 to 37, whereinthe first and second target master nodes and the target secondary node are configured to provide dual or multiple connectivity for the user equipment.

Images