Method for mobility enhancement

Abstract

The present disclosure relates generally to wireless communication technology, and more particularly to configuration and execution of layer 1 / layer 2 triggered mobility (LTM) and / or conditional LTM on a secondary cell group (SCG) level. Specifically, the SCG LTM can be initiated by a master node (MN) or by a source secondary node (SN). The SCG LTM can be implemented between SCGs or primary secondary cells (PSCells) within the source SN (intra-SN SCG LTM) or between different SNs (inter-SN SCG LTM). Various components of the wireless network coordinate at various network layers in order to prepare, configure, and / or execute the SCG LTM, including the MN, the source SN, and one or more candidate SNs, split or not split between their centralized unit (CU) and distributed unit (DU).

Description

Technical Field

[0001] This disclosure generally relates to wireless communication technologies, and more specifically to the configuration and execution of Layer-1 / Layer-2 Triggered Mobility (LTM) and / or Conditional LTM (CLTM) at the Secondary Cell Group (SCG) level. Background Technology

[0002] In wireless networks, wireless terminal devices communicating with the serving cell may need to hand over the cell while moving. It is desirable to perform such cell handovers with reduced mobility latency, data interruption time, communication overhead, and / or power consumption across various network architectures and topologies. Summary of the Invention

[0003] This disclosure generally relates to wireless communication technologies, and more specifically to the configuration and execution of Layer 1 / Layer 2 triggered mobility (LTM) and / or conditional LTM at the secondary cell group (SCG) level. Specifically, the SCG LTM can be initiated by a primary node (MN) or a source secondary node (SN). The SCG LTM can be implemented between SCGs or primary / secondary cells (PSCells) within the same SN (intra-SN SCG LTM), or between different SNs (inter-SN SCG LTM). Various components of the wireless network coordinate at various network layers to prepare, configure, and execute the SCG LTM, including the MN, source SN, and one or more candidate SNs, which may or may not be split between their centralized unit (CU) and distributed unit (DU).

[0004] In some example implementations, a method is disclosed that is performed by a primary node (MN) of a wireless network for serving a wireless terminal via a source primary-secondary cell (PSCell) in a secondary cell group (SCG), together with a source secondary node (SN). The method may include: initiating a Layer 1 / Layer 2 Triggered Mobility (LTM) preparation process to obtain an LTM configuration; transmitting the LTM configuration to the wireless terminal; determining, based on an L1 measurement set, to initiate an SCG LTM cell handover to allow the wireless terminal to hand over from the source PSCell to a target PSCell in the target SN; transmitting an LTM cell handover command to the wireless terminal to trigger the SCG LTM cell handover; and, upon the wireless terminal performing the SCG LTM cell handover from the source PSCell to the target PSCell, receiving a Radio Resource Control (RRC) completion message from the wireless terminal.

[0005] In the above example implementation, the LTM preparation process includes: transmitting an SN Add Request message to each of one or more candidate SNs, wherein the SN Add Request message to each of the one or more candidate SNs includes at least one of the following: an indication indicating that LTM is requested; an identifier of the one or more candidate SNs; one or more candidate cells recommended by the MN for the candidate SN; one or more candidate cells recommended by the MN for each of the other candidate SNs; a maximum number of candidate cells that the candidate SN can prepare for LTM; a list of SN keys and associated sk-counter values ​​of the candidate SNs; LTM candidate configuration IDs or ID ranges of the one or more candidate cells that the candidate SN can prepare; a mapping between LTM candidate configuration IDs and the one or more candidate cells; a request indication for SCG reference configuration; SCG reference cell configuration; a request indication for L1 reference signal (RS) configuration; a request indication for early TA acquisition resource configuration; or a request indication for TCI status configuration.

[0006] In any of the above example implementations, the LTM preparation process further includes: receiving an SN add request confirmation message from one or more candidate SNs, wherein the SN add request confirmation message from one or more candidate SNs includes at least one of the following: one or more prepared candidate SN DUIDs; one or more prepared candidate cell IDs; the SCG reference configuration in response to the request indication for the SCG reference configuration; a candidate SCG configuration for each of the one or more prepared candidate cells; an indicator for indicating whether the candidate SCG configuration of the corresponding candidate cell is a complete configuration relative to the SCG reference configuration; the L1 RS configuration of the one or more prepared candidate cells; the early UL synchronization configuration of the one or more prepared candidate cells; or the TCI state configuration of the one or more prepared candidate cells.

[0007] In any of the above example implementations, the LTM preparation process further includes: the MN sending an SN modification request message to the source SN or a candidate SN among the one or more candidate SNs to notify the candidate cell information prepared by the one or more candidate SNs.

[0008] In any of the above example implementations, the SN modification request message includes at least one of the following: an identifier of the one or more candidate SNs; one or more candidate SN DU IDs; one or more prepared candidate cell IDs; an LTM candidate configuration ID of the prepared candidate cell; an L1 RS configuration of the prepared candidate cell; an early UL synchronization configuration of the prepared candidate cell; a TCI state configuration of the prepared candidate cell; an SCG reference configuration; or a CSI resource configuration for performing L1 measurements on the prepared candidate cell.

[0009] In any of the above example implementations, the method may further include: the MN receiving an SN modification request confirmation message from the source SN or one or more candidate SNs in response to the SN modification request message.

[0010] In any of the above example implementations, the SN modification request confirmation message includes CSI resource configuration or updated SCG configuration for L1 measurement of the prepared candidate cell.

[0011] In any of the above example implementations, the LTM configuration includes one or more LTM candidate configurations.

[0012] In any of the above example implementations, the SCG LTM cell handover is performed based on the LTM candidate configuration of the target PSCell.

[0013] In any of the above example implementations, each of the one or more candidate LTM configurations includes an indicator for indicating whether the corresponding LTM candidate is for SCG LTM cell handover or MCG LTM cell handover.

[0014] In any of the above example implementations, the method may further include: determining the target PSCell for the SCG LTM cell handover based on L1 measurements of one or more candidate cells of one or more candidate SNs, and including information about the target PSCell in the LTM cell handover command.

[0015] In any of the above example implementations, determining the target PSCell for the SCG LTM cell handover includes one of the following: determining the target PSCell for the SCG LTM cell handover based on the L1 measurement within the DU of the MN; performing coordination between the DU and the CU of the MN to determine the target PSCell for the SCG LTM cell handover; or performing coordination between the MN and the target SN to determine the target PSCell for the SCG LTM cell handover.

[0016] In any of the above example implementations, the LTM cell handover command includes an LTM cell handover type indicator, which indicates whether the LTM cell handover command is for an SCG LTM cell handover or an MCG LTM cell handover.

[0017] In any of the above example implementations, the LTM cell handover command includes a Media Access Control (MAC) control element (MAC CE).

[0018] In any of the above example implementations, when the LTM cell handover type indicator indicates that the LTM cell handover command is for an SCG LTM cell handover, the SCG LTM cell handover also causes the wireless terminal to perform at least one of the following: instructing the upper or lower layer of the MAC layer that the LTM cell handover is for an SCG LTM cell handover; or performing LTM-related operations for the SCG LTM cell handover in the SCG MAC entity of the wireless terminal.

[0019] In any of the above example implementations, the LTM-related operations include at least one of the following: MAC reset, TA processing, selection of uplink grant configuration, or LTM handover without RACH (no random access channel).

[0020] In any of the above example implementations, initiating the SCG LTM cell handover further includes: sending a cell handover notification message to notify the target SN of information associated with the target PSCell, wherein the information associated with the target PSCell includes at least one of the following: the ID of the target PSCell or the TCI status ID of the target PSCell.

[0021] In any of the above example implementations, the method may further include at least one of the following: transmitting to the candidate SN a range of candidate configuration IDs for candidate cells proposed for LTM preparation; or receiving a mapping between candidate cells and candidate configuration IDs prepared by the candidate SN, the mapping being determined by the candidate SN based on the range of candidate configuration IDs.

[0022] In any of the above example implementations, the method may further include: after receiving the RRC completion message from the wireless terminal, initiating an SN modification or release procedure to the source SN to notify the source SN to: stop providing user data to the wireless terminal, or switch to a ready state.

[0023] In some other example implementations, a method performed by a wireless terminal is disclosed, wherein the wireless terminal is served by a source secondary node (SN) of a wireless network for serving the wireless terminal via a source primary secondary cell (PSCell) and a primary node (MN) in a secondary cell group (SCG). The method may include: receiving a Layer 1 / Layer 2 triggered mobility (LTM) configuration from the MN; receiving an LTM cell handover command from the MN; and performing an SCG LTM cell handover from the source PSCell to a target PSCell of the target SN according to the LTM cell handover command and the LTM configuration.

[0024] In the above example implementation, the method may further include: performing UL synchronization with the candidate SN before receiving the LTM cell handover command for use in the SCG LTM cell handover.

[0025] In any of the above example implementations, the UL synchronization includes: receiving random access indication signaling from the source SN to trigger the UL synchronization via an early random access procedure between the wireless terminal and the candidate SN.

[0026] In any of the above example implementations, the LTM cell handover command includes information associated with the target PSCell, which is determined by: determining it within the DU of the MN; determining it through coordination between the DU and the CU of the MN; or determining it through coordination between the MN and the target SN.

[0027] In any of the above example implementations, the LTM cell handover command includes an LTM cell handover type indicator, which indicates whether the LTM cell handover command is for an SCG LTM cell handover or an MCG LTM cell handover.

[0028] In any of the above example implementations, the LTM cell handover command includes a Media Access Control (MAC) control element (MAC CE).

[0029] In any of the above example implementations, when the LTM cell handover type indicator indicates that the LTM cell handover command is for SCG LTM cell handover, the SCG LTM cell handover further includes performing at least one of the following: indicating to the upper or lower layer of the MAC layer that the LTM cell handover command is for SCG LTM cell handover; or performing LTM-related operations for the SCG LTM cell handover in the SCG MAC entity of the wireless terminal.

[0030] In any of the above example implementations, the LTM-related operations include at least one of the following: MAC reset, TA processing, selection of uplink grant configuration, or LTM handover without RACH (no random access channel).

[0031] In some other implementations, a wireless communication device is disclosed. The wireless communication device may include a processor and a memory, wherein the processor is configured to read code from the memory and implement any of the methods described above.

[0032] In several other implementations, a non-transitory computer-readable medium is disclosed. This non-transitory computer-readable medium may include computer instructions that, when executed by a processor of a wireless communication device, cause the wireless communication device to implement any of the methods described above. Attached Figure Description

[0033] Figure 1 An example wireless communication network including a wireless access network, a core network, and a data network is shown.

[0034] Figure 2 An example radio access network is shown, comprising multiple mobile stations / terminals or user equipment (UE) communicating with each other via an over-the-air wireless communication interface and radio access network nodes.

[0035] Figure 3 An example radio access network (RAN) architecture is shown.

[0036] Figure 4 An example communication protocol stack is shown in a wireless access network node or wireless terminal device that includes various network layers.

[0037] Figure 5 An example LTM process is shown.

[0038] Figure 6 An example conditional LTM procedure is shown.

[0039] Figure 7An example process for preparing an inter-SN LTM initiated by a secondary node (SN) is shown.

[0040] Figure 8 This illustrates an example process for preparing an inter-SN LTM initiated by the Master Node (MN).

[0041] Figure 9 The example SN-triggered early synchronization process and / or secondary cell group (SCG) LTM cell handover execution process is shown.

[0042] Figure 10 The example MN-triggered early synchronization process and / or secondary cell group (SCG) LTM cell handover execution process is shown.

[0043] Figures 11 to 12 This illustrates an example overall process for an SN-initiated inter-SN LTM.

[0044] Figures 13 to 14 An example overall process for an MN-initiated inter-SN LTM is shown.

[0045] Figure 15 An example of a subsequent cell handover is shown. Detailed Implementation

[0046] This disclosure will now be described in detail with reference to the accompanying drawings, which form part of this disclosure and illustrate specific examples of embodiments by way of example. However, this disclosure may be implemented in many different forms, and therefore the subject matter covered or claimed should not be construed as limited to any of the embodiments set forth below.

[0047] Throughout the specification and claims, terms may have nuanced meanings implied or implied in the context that go beyond their expressly stated meanings. Similarly, the phrases “in one embodiment” or “in some embodiments” as used herein do not necessarily refer to the same embodiment, and the phrases “in another embodiment” or “in other embodiments” as used herein do not necessarily refer to different embodiments. Likewise, the phrases “in one implementation” or “in some implementations” as used herein do not necessarily refer to the same implementation, and the phrases “in another implementation” or “in other implementations” as used herein do not necessarily refer to different implementations. For example, the subject matter intended to be claimed includes all or part of the exemplary embodiments or combinations of implementations.

[0048] Generally, terms can be understood, at least in part, from their use in context. For example, terms such as “and,” “or,” or “and / or,” as used herein, can have multiple meanings that can depend, at least in part, on the context in which they are used. Typically, if “or” is used with an associative list, such as A, B, or C, it is intended to mean A, B, and C (used herein in an inclusive sense) and A, B, or C (used herein in an exclusive sense). Furthermore, the terms “one or more” or “at least one,” as used herein, can be used, at least in part, to describe any feature, structure, or characteristic in a singular sense, or to describe a combination of features, structures, or characteristics in a plural sense, depending at least in part on the context. Similarly, terms such as “a,” “an,” or “the” can also be understood to convey either a singular or plural usage, depending at least in part on the context. Moreover, the terms “based on” or “determined by” can be understood to not necessarily convey an exclusive set of factors and can allow for additional factors that are not necessarily explicitly described, again depending at least in part on the context.

[0049] Wireless Network Overview like Figure 1 As shown in Figure 100, the example wireless communication network may include wireless terminal equipment or user equipment (UE) 110, UE 111, and UE 112, carrier network 102, various service applications 140, and other data networks 150. The wireless terminal equipment or UE may alternatively be referred to as a wireless terminal. For example, carrier network 102 may include access network nodes 120 and 121, and a core network 130. Carrier network 110 may be configured to transmit voice, data, and other information (collectively referred to as data traffic) between the UE and service application 140 or between the UE and other data networks 150. Access network nodes 120 and 121 may be configured as various wireless access network nodes (WANNs, alternatively referred to as wireless base stations) to interact with the UE at one end of the communication session and with the core network 130 at the other end. The term "access network" may be used more broadly to refer to the combination of wireless terminal devices 110, 111, and 112 with access network nodes 120 and 121. The radio access network may also be referred to as the Radio Access Network (RAN). The core network 130 may include various network nodes configured to control communication sessions and perform network access management and traffic routing. Service applications 140 may be hosted by various application servers deployed outside of but connected to the core network 130. Similarly, other data networks 150 may also be connected to the core network 130.

[0050] exist Figure 1 In the example wireless communication network 100, each UE can communicate with each other through a wireless access network. For example, UE 110 and UE 112 can be connected to the same access network node 120 and communicate through the same access network node 120. Each UE can communicate with each other through both the access network and the core network. For example, UE 110 can be connected to access network node 120, and UE 111 can be connected to access network node 121, and thus, UE 110 and UE 111 can communicate with each other through access network nodes 120 and 121, as well as the core network 130. UEs can also communicate with service applications 140 and data networks 150 through the core network 130. In addition, each UE can communicate directly with each other through sidelink communication (as shown in 113).

[0051] Figure 2 An example system diagram of a radio access network 120 is also shown, which includes a WANN 202 serving UE 110 and UE 112 via an air interface 204. The radio transmission resources of the air interface 204 include a combination of frequency resources, time resources, and / or spatial resources. Each of UE 110 and UE 112 can be a mobile or fixed terminal device equipped with a mobile access unit such as a SIM / USIM (Subscriber Identity Module / Universal Subscriber Identity Module) module to access the wireless communication network 100. Both UE 110 and UE 112 can be implemented as terminal devices including, but not limited to, mobile phones, smartphones, tablets, laptops, in-vehicle communication devices, roadside communication devices, sensor devices, smart home appliances (such as televisions, refrigerators, and ovens), or other devices capable of wireless communication over a network. Figure 2 As shown, each of these UEs (such as UE 112) may include transceiver circuitry 206 coupled to one or more antennas 208 for enabling wireless communication with WANN 120 or another UE (such as UE 110). Transceiver circuitry 206 may also be coupled to processor 210, which may also be coupled to memory 212 or other storage devices. Memory 212 may be transient or non-transient and may store computer instructions or code that, when read and executed by processor 210, cause processor 210 to implement the methods described herein.

[0052] Similarly, WANN 120 may include a wireless base station or other wireless network access point capable of wirelessly communicating with one or more UEs via air interface 204 and with core network 130. For example, WANN 120 may not be implemented in the form of a 2G base station, 3G nodeB, LTE eNB, 4G LTE base station, 5G gNB 5G NR (New Radio) base station, 5G centralized unit base station, or 5G distributed unit base station. Each type of WANN may be configured to perform a corresponding set of wireless network functions. WANN 202 may include transceiver circuitry 214 coupled to one or more antennas 216, which may include various forms of antenna towers 218, to enable wireless communication with UEs 110 and UE 112. Transceiver circuitry 214 may be coupled to one or more processors 220, which may be further coupled to memory 222 or other storage devices. The memory 222 may be transient or non-transient, and may store instructions or code that, when read and executed by one or more processors 220, cause one or more processors 220 to perform the various functions of the WANN 120 described herein.

[0053] like Figure 2 In the example shown, data packets in a radio access network can be transmitted as protocol data units (PDUs). The data included can be encapsulated into PDUs at various network layers, with nested and / or layered protocol headers. When a connection is established between the transmitting and receiving ends (e.g., a radio link control (RRC) connection), communication between the transmitting device or receiving end (these two terms are used interchangeably) and the receiving device or receiving end (these two terms are also used interchangeably) can occur between the PDUs. Either the transmitting or receiving device can be a wireless terminal device (such as…) Figure 2 Devices 110 and 120), or wireless access network nodes (such as...) Figure 2 (Node 202). Each device can be both a sending device and a receiving device for bidirectional communication.

[0054] Figure 1 The core network 130 may include various geographically distributed and interconnected network nodes to provide network coverage over the service area of ​​the carrier network 102. These network nodes may be implemented as dedicated hardware network nodes. Alternatively, these network nodes may be virtualized and implemented as virtual machines or software entities. Each of these network nodes may be configured with one or more types of network functions that collectively provide resource provisioning and routing capabilities for the core network 130.

[0055] Return to the Radio Access Network (RAN). Figure 3 An example RAN 340 communicating with core network 310 and radio terminals UE1 through UE7 is shown. RAN 340 may include one or more radio base stations of various types or WANNs 320 and 321, which may include, but are not limited to, gNBs, eNodeBs, NodeBs, or other types of base stations. RAN 340 may have backhaul connections to core network 310. For example, WANN 320 may further include multiple separate access network nodes in the form of a Central Unit (CU) 322 and one or more Distributed Units (DUs) 324 and 326. CU 322 is connected to DU1 324 and DU2 326 via various interfaces (e.g., F1 interfaces). For example, the F1 interface may further include an F1-C interface and an F1-U interface, which may be used to carry control plane information and user plane data, respectively. In some embodiments, CU may be a gNB Central Unit (gNB-CU), and DU may be a gNB Distributed Unit (gNB-DU). While the various implementations described below are provided in the context of 5G cellular wireless networks, the underlying principles described herein are applicable to other types of wireless access networks, including but not limited to other generations of cellular networks, as well as Wi-Fi, Bluetooth, ZigBee, and WiMax networks.

[0056] Each UE can be connected to the network via the air interface through the WANN 320. Each UE can be served by at least one cell. Each cell is associated with a coverage area. These cells are alternatively referred to as serving cells. The coverage areas between cells may partially overlap. Each UE may actively communicate with at least one cell when it is potentially connectable to or able to connect to more than one cell. In some example implementations, Figure 3 A DU can support one or more cells, and a cell is supported by only one DU. Figure 3 In the example, UE1, UE2, and UE3 can be served by cell 1 330 of DU1, while UE4 and UE5 can be served by cell 2 332 of DU1, and UE6 and UE7 can be served by cell 3 associated with DU2. In some implementations, a UE can be served by two or more cells simultaneously. Each UE can be mobile, and the signal strength and quality at the UE from the various cells can depend on the UE's location and mobility.

[0057] Figure 4 Further demonstrated in Figures 1 to 3A simplified diagram of the various network layers involved in transmitting a user plane PDU from transmitting device 402 to receiving device 404 in an example wireless access network. Figure 4 It is not intended to include all the necessary equipment components or network layers for handling the transmission of PDUs. Figure 4 This illustrates that the data encapsulated in the upper network layer 420 of the transmitting device 402 can pass through the packet data convergence protocol layer (PDCP) of the transmitting device. Figure 4 The PDUs (not shown in the diagram) and the radio link control (RLC) layer 422, the physical (PHY) layer and radio interface (as shown in 406) of the transmitting and receiving devices, and the media access control (MAC) layer 434 and RLC layer 432 of the receiving device are transmitted to the corresponding upper layer 430 of the receiving device 304 (such as the radio resource control or RRC layer). Various network entities in each of these layers can be configured to handle the transmission and retransmission of PDUs.

[0058] exist Figure 4 In the middle, the upper layer 420 can be referred to as layer 3 or L3, while the intermediate layers (such as RLC layers and / or MAC layers and / or PDCP layers) are... Figure 4 (Not shown in the diagram) can be collectively referred to as layer 2 or L2, and the term layer 1 is used to refer to layers such as the physical layer and the radio interface association layer. In some instances, the term "lower layer" can be used to refer to the set of L1 and L2, while the term "higher layer" can be used to refer to layer 3. In some cases, the term "lower layer" can be used to refer to layers among L1, L2, and L3 that are lower than the current reference layer. Control signaling can be initiated and triggered within each of the layers L1 through L3 and the various network layers within them. These signaling messages can be encapsulated and concatenated into lower-layer packets and transmitted through allocated control or data air radio resources and interfaces. The term "layer" typically includes its various corresponding entities. For example, the MAC layer covers the corresponding MAC entities that can be created. Layer 1 (L1) covers, for example, the PHY entity. Layer 2 (L2) covers, for example, the MAC layer / entity, the RLC layer / entity, the Service Data Adaptation Protocol (SDAP) layer, and / or the PDCP layer / entity.

[0059] exist Figure 3In some example CU / DU separation implementations shown, CU 322 can be defined as a logical node that hosts the higher-layer RRC, SDAP, and PDCP protocols of the example gNB or the RRC and PDCP protocols or protocol entities of the example en-gNB, and controls the operation of one or more example DUs 324 and 326. Example DUs 324 and 326 can each be defined as logical nodes that host the lower-layer RLC, MAC, and PHY protocols or protocol entities of the gNB or en-gNB, their operation partially controlled by CU 322.

[0060] In some example implementations, Figure 3 The cells shown can be alternatively referred to as serving cells. These serving cells can be grouped into serving cell groups (CGs). A serving cell group can be a master CG (MCG) or a secondary CG (SCG). Within each type of cell group, there can be one master cell and one or more secondary cells. For example, the master cell in an MSG can be called a PCell, while the master cell in an SCG can be called a PSCell. Secondary cells in either an MCG or an SCG can be called SCells. Master cells that include both PCells and PSCells can be collectively referred to as spCells (special cells). All of these cells can be referred to as serving cells or cells. The terms "cell" and "serving cell" can be used interchangeably in general unless specifically distinguished. The term "serving cell" can refer to a cell that is currently serving, will be serving, or may serve a UE. In other words, a "serving cell" may not currently be serving a UE. While the various embodiments described below may sometimes involve one of the above-described serving cell types, the underlying principles apply to all types of serving cells in both types of serving cell groups.

[0061] L1 / L2 Triggered Mobility (LTM) LTM is a process in which the gNB (typically representing a base station) receives an L1 measurement report from the UE, and based on this, the gNB changes the UE's serving cell via a cell handover command, for example, transmitted via MAC CE signaling. The cell handover command designates an LTM candidate cell as the target cell, which has a cell configuration previously prepared by the gNB and provided to the UE via RRC signaling. The UE then hands over to the target cell according to the cell handover command. The cell handover command can be transmitted in the MAC CE, which contains the necessary information for performing the LTM cell handover.

[0062] The overall example process of LTM is as follows: Figure 5As shown, for example, it includes the LTM preparation process, the early synchronization process, the LTM cell handover execution process, and the LTM cell handover completion process. Subsequent LTM operations are completed by repeating the early synchronization, LTM cell handover execution, and LTM cell handover completion steps, without releasing the configuration of other LTM candidate cells after each LTM cell handover. Figure 5 This can be applied to scenarios where cell handover is within a CU; therefore, only one gNB is shown, and LTM cell handover can occur between a source cell and a target cell associated with the same gNB. Figure 5 The example overall process can be applied to primary cell group (MCG) LTM cell handover and / or secondary cell group (SCG) LTM cell handover.

[0063] LTM Figure 5 The overall process of the example is described below. Numerical headings indicate... Figure 5 The corresponding steps.

[0064] 1. During the current communication connection with the source cell associated with the gNB, the UE sends a Measurement Report message to the gNB. The gNB receives the Measurement Report message and then decides to initiate LTM preparation to configure future LTM cell handover based on the Measurement Report message.

[0065] 2. The gNB sends an RRC Reconfiguration message to the UE, which includes the LTM candidate cell configuration of the candidate cells.

[0066] 3. The UE stores the LTM candidate cell configuration and transmits an RRC reconfiguration complete message to the gNB. Steps 1 to 3 can be referred to as the LTM preparation process.

[0067] 4a. The UE may perform downlink (DL) synchronization with one or more candidate cells before receiving a cell handover command.

[0068] 4b. If configured / indicated by the network, the UE may perform UE-based Time Advance (TA) measurement or PDCCH command-triggered early RACH to acquire TA values ​​for one or more candidate cells before receiving a cell handover command. For UE-based Time Advance (TA) measurement, the UE performs TA measurement for candidate cells after RRC configuration, but the exact timing of the TA measurement depends on the UE implementation. For PDCCH command-triggered early RACH, this can be accomplished via Contention-Free Random Access (CFRA) triggered by a Physical Downlink Control Channel (PDCCH) command from the source cell, after which the UE sends a preamble to the indicated candidate cell. The indicated candidate cell then calculates the TA value. To minimize data transmission interruptions to the source cell currently communicating with the UE due to CFRAs to one or more candidate cells, the candidate cells may not transmit, and the UE may not receive, Random Access Responses (RARs) for TA value acquisition. The TA values ​​of the candidate cells may be indicated in the cell handover command given to the UE. The UE may not maintain TA timers for the candidate cells, but can rely on network implementations to ensure TA validity. Steps 4a and 4b above can be referred to as the early synchronization process.

[0069] 5. The UE performs L1 measurements on one or more configured candidate cells and transmits an L1 measurement report to the gNB. L1 measurements should be performed whenever the UE applies the RRC reconfiguration message received in step 2.

[0070] 6. The gNB can decide to perform a cell handover to a target cell (among candidate cells) and transmit, for example, a MACCE, which triggers the cell handover by including a candidate configuration index of the target cell (used to identify the target cell configuration among one or more candidate cells). The UE can then handover to the target cell and apply the cell configuration indicated by the candidate configuration index.

[0071] 7. If the UE has not yet obtained a valid TA for the target cell from, for example, the synchronization process described above, the UE performs a random access procedure to the target cell. If the UE has already obtained a valid TA for the target cell, the random access procedure in step 7 can be omitted. Steps 5 to 7 described above can be referred to as the LTM cell handover execution process.

[0072] 8. The UE completes the LTM cell handover process by sending an RRC Reconfiguration Complete message to the target cell. If the UE performed a random access procedure in step 7 above, the UE can consider the LTM cell handover execution to be successfully completed when the random access procedure is successfully completed. For LTM without RACH (where step 7 is omitted), the UE can instead consider the LTM cell handover execution to be successfully completed when the UE determines that the network has successfully received its first UL data.

[0073] The LTM candidate configuration provided in step 2 can be used to execute steps 4 to 8 above multiple times for subsequent LTMs.

[0074] Conditional mobility Conditional mobility can be implemented during cell handover, where the UE determines the cell to be handed over based on pre-configured conditions rather than cell handover commands from the network. Conditional mobility can include conditional LTM (CLTM) and conditional L3 mobility. In some example implementations, conditional mobility can be applied to LTM, i.e., CLTM. In some other example implementations, conditional L3 mobility can include, for example, at least one of Conditional Handover (CHO), Conditional LTM, Conditional PSCell Addition (CPA), Conditional PSCell Change (CPC), and subsequent Conditional PScell ​​Addition / Change (CPAC). In the following disclosure, some relevant parts, although described in the context of LTM, can be applied to either type of conditional mobility.

[0075] The term Conditional LTM (CLTM) can be used specifically to refer to an LTM cell handover performed by the UE when one or more execution / triggering conditions are met. The UE may begin evaluating the execution conditions after receiving the CLTM configuration and stop evaluating the execution conditions when a cell handover or PCell / PSCell change is triggered (e.g., according to the CLTM configuration or a cell handover (switch / handover) command from the NW).

[0076] CLTM is generally applicable to MCG cell handover and / or SCG cell handover. The LTM-related configurations described above can be applied to the underlying LTM's CLTM.

[0077] The example overall process of CLTM is as follows: Figure 6 As shown, it is applicable to CLTM within and between CUs. Figure 6 In the overall CLTM process, the gNB in ​​the inter-CU LTM case will correspondingly include the source gNB and the target gNB. Although in Figure 6 The notation "gNB" is used in the various example implementations described below for CLTM, but it can be considered to represent any type of base station. Each such base station can include a CU and one or more DUs, such as... Figure 3 As shown. It can also represent a combination of source gNB and target gNB for CLTM purposes between CUs. Figure 6 The example overall process of CLTM shown may include the following example steps (the numbered headings below correspond to...) Figure 6 (Steps in the process) 1. The UE sends a measurement report message to the gNB. The gNB decides to configure CLTM and initiates CLTM preparation.

[0078] 2. The gNB sends an RRC reconfiguration message to the UE, which includes CLTM configuration, such as one or more candidate configurations and one or more execution conditions for each candidate.

[0079] 3. The UE stores the candidate configuration and transmits the RRC reconfiguration complete message to the gNB.

[0080] 4a. The UE can perform DL synchronization with (one or more) candidate cells.

[0081] 4b. The UE may perform UL synchronization with one or more candidate cells, for example, via early RACH triggered by UE-based TA measurements or PDCCH.

[0082] 5. Upon receiving the CLTM configuration, the UE maintains a connection with the source gNB, and begins evaluating the execution conditions for one or more CLTM candidate cells whenever the UE applies the RRC reconfiguration message received in step 2. If at least one CLTM candidate cell meets one or more corresponding execution conditions, the UE selects a candidate cell to perform an LTM cell handover, for example, by separating from the source cell of the source gNB, and applies the stored corresponding candidate configuration for the selected candidate cell (i.e., the target cell). If the UE has not yet obtained a valid TA for the target cell, the UE performs a random access (RA) procedure to the target cell. If the UE has already obtained a valid TA for the target cell, the UE performs a cell handover to the target cell without RACH.

[0083] 6. The UE completes the LTM cell handover process by sending an RRC reconfiguration complete message to the target cell. If the UE performed the RA procedure in step 5 above, the UE considers the LTM cell handover execution to be successfully completed when the RA procedure is successfully completed. For LTM without RACH, the UE considers the LTM cell handover execution to be successfully completed when it determines that the network has successfully received its first UL data.

[0084] The LTM candidate configuration and execution conditions provided in step 2 can be used to execute steps 4 to 6 above multiple times for subsequent CLTMs.

[0085] Extended LTM In some example implementations, Figure 5 The overall process and underlying principles of LTM can be extended to Figure 6 The conditional LTM. Furthermore... Figure 5 LTM and Figure 6 Conditional LTM can be further applied or extended to scenarios beyond the CU. For example, such LTM and / or conditional LTM can be applied to inter-CU cell handover, and also to, for example, inter-DU cell handover within the CU and intra-DU cell handover within the CU.

[0086] As an example, this extended LTM or conditional LTM can support at least one of the following scenarios: • LTM in stand-alone (SA) or carrier aggregation (CA) networks; • MCG LTM in dual-connect DC (e.g., NR-DC), including, for example, MCG LTM cell handover with SCG / SN (secondary cell group / secondary node) release, MCG LTM cell handover with SCG / SN addition, MCG LTM cell handover without SCG / SN change, or MCG LTM cell handover with SCG / SN change. • SCG LTM in DC (e.g., NR-DC), including SCG LTM cell handover with MCG / MN (primary cell group / primary node) change / participation, or SCG LTM cell handover without MCG / MN change / participation.

[0087] In the following disclosure, the term SCG LTM can be defined as a PSCell / SCG handover / change process triggered by a network (NW) via a MAC CE based on L1 measurements. The term SCG LTM can include intra-SN cases (e.g., the source and target cells belong to the same SN CU) and inter-SN cases (e.g., the source and target cells belong to different SN CUs). From the perspective of the initiating node preparing the LTM, SCG LTM can be classified as MN-initiated SCG LTM or SN-initiated SCG LTM. From the perspective of MN participation, SCG LTM can be classified as intra-SN SCG LTM without MN participation, intra-SN SCG LTM with MN participation, and inter-SN SCG LTM initiated by MN / SN.

[0088] Figure 5 and Figure 6 The overall LTM and CLTM implementations can be applied to all these different scenarios. Figure 5 and Figure 6 In the case of inter-CU LTM, the gNB in ​​the context will correspondingly include the source gNB and the target gNB (and / or other candidate gNBs). Although in Figure 5 and Figure 6 The symbol "gNB" is used in the various example implementations described below, but it can be considered to represent any type of base station. Each such base station can include a CU and one or more DUs, such as Figure 3 As shown.

[0089] While the following description focuses primarily on inter-SN SCG LTM, the underlying principles and similar methods / procedures can also be applied to other LTM scenarios, such as intra-SN SCG LTM and MCG LTM. Unless otherwise stated, the disclosures below apply to either or both of MCG LTM and SCG LTM. In the disclosures below concerning SCG LTM, the term "candidate cell" is used to refer to an SCG candidate cell (e.g., a candidate PSCell). LTM-related configurations / procedures can also be applied to CLTM.

[0090] LTM related configuration In order to Figure 5The LTM preparation process applies to both intra-CU and inter-CU LTM implementations. The RRC reconfiguration message in step 2 can be provided to the UE by the current source gNB, and it can contain an information element (IE) called LTM-related configuration (e.g., LTM_Config). This LTM-related configuration, as the IE of the RRC reconfiguration message, can include various fields specifying LTM-related configurations for various candidate cells. For example, the LTM-related configuration can include a field specifying configurations / parameters that are LTM-related and common to all candidate cells (for intra-CU LTM, associated with the current source gNB; or for inter-CU LTM, associated with another candidate gNB). As an example of such common fields, the LTM-related configuration can include a reference cell configuration or a list of reference cell configurations. Each of these reference cell configurations can contain all or part of the cell configurations / parameters common to a set of candidate cells (e.g., identified by a cell group ID). In some example implementations, each reference cell configuration can be included as an RRC container in the LTM-related configuration message, which is associated with another RRC reconfiguration message that includes reference cell configuration information.

[0091] For example, LTM-related configurations can be in the form of a list of configurations for candidate cells, including configurations / parameters specific to each candidate cell. The list of candidate cells can be added, deleted, and modified. Each list item can include cell-specific information items that specify the LTM configuration / parameters specific to the corresponding candidate cell. Each list item can be referred to as an LTM candidate configuration for a specific candidate cell. In some example implementations, one of the cell-specific information items in the LTM candidate configuration can indicate the candidate cell configuration. For example, such a cell configuration for a specific candidate cell can be implemented as an RRC container associated with another RRC reconfiguration message that includes the cell configuration (candidate cell configuration) of the corresponding candidate cell. This configuration can be a full / complete cell configuration or an incremental cell configuration relative to the aforementioned reference cell configuration. If an incremental cell configuration is used, the ID of the corresponding reference cell configuration can be specified as a field in the cell-specific information item for the corresponding candidate cell in the list described above.

[0092] In the following disclosure, the term "LTM-related configuration" may be used to refer to the configuration of all candidate cells related to LTM, and these configurations may be included in RRC reconfiguration messages (e.g. Figure 5 In step 2, the transmitted RRC reconfiguration message is included.

[0093] Furthermore, in this disclosure, the term "LTM candidate configuration" may be used to refer to a configuration associated with a candidate cell and that may be included in an LTM-related configuration.

[0094] Furthermore, in this disclosure, the term "candidate cell configuration," referring to the RRC configuration of a candidate cell, can be used to refer to a configuration specific to a candidate cell and can be implemented as an RRC container that includes an RRC reconfiguration message. Such an RRC reconfiguration message carrying the candidate cell configuration may include, for example, parameters required for cell handover, such as RadioBearerConfig, CellGroupConfig, MeasConfig, MasterKeyUpdate, and / or OtherConfig, as described in further detail below. For example, the candidate cell configuration may be a complete candidate configuration or an incremental configuration relative to a reference configuration.

[0095] Furthermore, in this disclosure, the term "reference configuration" can be used to refer to an RRC configuration provided to the UE by the network that is common to a group of cells within the same cell group. The reference configuration can be a complete or incomplete cell configuration. When the reference configuration is incomplete, it can be combined with the incremental configuration of candidate cells to derive the complete configuration of the candidate cells.

[0096] Furthermore, in the following disclosure, the “candidate cell configuration” or “reference configuration” mentioned above is merely an example and can be implemented as being transmitted in an RRC reconfiguration message that carries LTM-related configurations, via an RRC reconfiguration message included within a container.

[0097] In some example scenarios and implementations, such as for intra-SN SCG LTMs involving an MN or inter-SN SCG LTMs initiated by an MN / SN, the SCG LTM configuration (e.g., referred to as LTM_Config) can be provided / generated by the MN and thus can be correspondingly referred to as, for example, "MN-generated LTM configuration," "MN-formatted LTM," or "LTM associated with an MCG." The LTM candidate cell configuration may include the SCG portion of the configuration and may also include the MCG portion of the configuration. The SCG LTM configuration can be included in the MN RRC reconfiguration message and sent to the UE via SRB 1 (Signaling Radio Bearer 1). The UE can store the received LTM-related configuration (e.g., LTM candidate cell configuration) in a UE variable associated with the MCG.

[0098] In other example scenarios and implementations, such as for intra-SN SCG LTM without MN involvement, the SCG LTM configuration can be provided / generated by the source SN and can be correspondingly referred to as "SN-generated SCG LTM configuration" or "SN-formatted SCG LTM". Therefore, the LTM candidate cell configuration may only include the SCG portion of the configuration. The SCG LTM configuration included in the SN RRC reconfiguration message can be sent to the UE via SRB3, or embedded in the MN RRC reconfiguration message and sent to the UE via SRB1. The UE can store the received LTM-related configuration (e.g., LTM candidate cell configuration) in UE variables associated with the SCG.

[0099] As an example, the LTM-related configurations provided to the UE by the serving cell of the network (e.g., the source gNB) may include, but are not limited to, one or more of the following: • One or more reference cells are configured; • One or more LTM candidate configurations (e.g., forming a configuration list, with each configuration corresponding to a candidate cell); • List / pool of Channel State Information (CSI) resource-related configurations, for example, for L1 measurements; • Serving cell No Reset ID, for example, ltm-ServingCellNoResetID, as will be described in further detail below, the UE determines whether an L2 reset (e.g., PDCP data recovery, RLC reconstruction) should be performed when triggering an LTM cell handover procedure to an LTM candidate cell by comparing the Serving Cell No Reset ID with the No Reset ID associated with the candidate cell (whether they are the same or different). • Serving cell UE measurement TA ID, for example, ltm-ServingCellUE-MeasuredTA-ID, as will be described in further detail below, the UE determines whether it can perform UE-based TA measurement for the candidate cell by checking whether the serving cell UE measurement TA ID is the same as or different from the UE measurement TA ID associated with the candidate cell; • Indicators for recovery based on MCG LTM, for example, indicating whether recovery based on LTM is allowed in the event of MCG RadioLink Failure (RLF) or mobility failure; • Indicators for SCG-based LTM recovery, for example, indicating whether LTM-based recovery is allowed in the event of SCG failure (e.g., SCG radio link failure (RLF) or mobility failure); • The serving cell security update ID, such as securityCellSetId, as will be described in further detail below, is used by the UE to determine whether a security update should be performed when triggering an LTM cell handover procedure to an LTM candidate cell by comparing the serving cell security update ID with the security update ID associated with the candidate cell (whether they are the same or different). • One or more security-related configurations.

[0100] In some example implementations, each LTM candidate configuration within the LTM-related configurations described above (provided for each LTM candidate cell) may include, but is not limited to, at least one of the following information items for the candidate cell: • LTM candidate configuration ID; • Physical Cell ID (PCI) information of candidate cells; • System Synchronization Block (SSB) related configurations, such as configuration / information for L1 measurement or Transmission Configuration Indication State (TCI state); • CSI-Reference Signal (CSI-RS) related configurations, such as those used for L1 measurements or TCI status configuration / information; • Candidate cell configuration; • An indicator used to indicate whether the candidate cell configuration is complete; • Early UL synchronization configuration, such as contention-free random access (CFRA) resource configuration; • TCI status configuration / information, such as DL or combined TCI status list, UL TCI status list; • Candidate cell has no reset ID, for example, ltm-NoResetID. The UE determines whether an L2 reset (e.g., PDCP data recovery, RLC reconstruction) should be performed when triggering an LTM cell handover procedure to an LTM candidate cell by comparing the candidate cell's no reset ID with the no reset ID associated with the current serving cell (whether they are the same or different). • UE Measurement TA ID, for example, ltm-UE-MeasuredTA-ID. The UE determines whether it can perform a UE-based TA measurement to obtain the TA of the indicated candidate cell by checking whether the UE Measurement TA ID of the candidate cell is the same as or different from the UE Measurement TA ID associated with the current serving cell. • Security update ID, such as securityCellSetId, is used by the UE to determine whether a security update should be performed when triggering an LTM cell handover procedure to an LTM candidate cell by comparing the candidate cell security update ID with the security update ID associated with the current serving cell (whether they are the same or different). • Reference Configuration ID, used by the UE to identify the reference cell configuration. As will be described in further detail below, the reference configuration can be combined with the candidate cell configurations (if partial) mentioned above to derive the full / complete candidate cell configuration; • Indication used to indicate whether a candidate cell is used for MCG LTM or SCG LTM, or to indicate whether a candidate cell is configured as a candidate PCell or a candidate PSCell.

[0101] The above reference configurations are provided to reduce the signaling overhead of candidate cell configurations (so that the cell configuration common to multiple candidate cells only needs to be transmitted once by signaling, and each candidate cell configuration only needs to include the incremental cell configuration). For example, the NW can provide multiple reference configurations for LTM candidate cell configurations, where, for example, each of these reference configurations corresponds to a CU (or a candidate gNB).

[0102] In some of the example implementations described above, one or more reference configurations may include a list of reference configurations for adding / modifying (e.g., ltm-ReferenceToAddModList) and / or a list of reference configurations for releasing (e.g., ltm-ReferenceToReleaseList). In some example implementations, each configuration item in the list may be an RRC container containing an RRC reconfiguration message for the reference configuration.

[0103] In some example implementations, each reference configuration is associated with a reference configuration ID.

[0104] In some implementations, as described above, the candidate cell configuration can be associated with a reference configuration ID, which can be used by the UE, for example, to determine which reference can be used alone or in combination with the candidate cell's cell configuration to generate the complete candidate configuration of the candidate cell. Specifically, for an LTM candidate cell configured for incremental purposes (e.g., the corresponding LTM candidate configuration does not include a complete configuration indicator), the UE can apply its LTM candidate configuration on top of the reference configuration associated with that LTM candidate (e.g., via the reference configuration ID associated with that candidate cell configuration) to generate the complete cell configuration of that LTM candidate cell.

[0105] L1 Measurement Configuration In some example implementations, the network (NW) can also provide the UE with L1 measurement-related configurations for candidate cells (e.g., L1 measurement reference signal (RS) configuration, CSI resource configuration, L1 measurement report configuration, etc.). Some parts of the L1 measurement-related configurations (e.g., L1 measurement RS configuration, CSI resource configuration) can be included in the LTM-related configurations mentioned above. Other items of the L1 measurement-related configurations (e.g., L1 measurement report configuration) can be included in the serving / candidate cell configuration of the corresponding cell.

[0106] L1 measurement-related configurations (or the execution conditions of SCG CLTM as described below) can be generated by various network nodes. For example, they can be generated from the following: Option 1: SN (e.g., source SN or candidate SN) for SCG LTM initiated by, for example, MN or SN.

[0107] Option 2: MN, for example, for SCG LTM initiated by MN.

[0108] Security-related configurations While intra-CU LTMs may not require updating the security key, inter-CU LTMs (e.g., subsequent inter-CU LTMs) may. Therefore, for systems implementing inter-CU LTMs, the issue of security key reuse and updates needs to be considered.

[0109] Security-related configurations may include a list of security update configurations for adding / modifying (e.g., called ltm-SecurityConfigToAddModList) and / or a list of security update configurations for releasing (e.g., called ltm-SecurityConfigToReleaseList). Each security update configuration may include at least one of the following: a security update ID (e.g., called securityCellSetId) and one or more security parameters (e.g., a list of sk-Counter values).

[0110] In some example implementations, when SCG LTM or CLTM is triggered, if the security update ID associated with the target candidate cell is not equal to the security update ID associated with the serving cell, the UE should (e.g., via the security update ID) select the first sk-counter value in the list of sk-counter values ​​associated with the target candidate cell and perform a security key update using the selected sk-counter value. The UE can also remove the selected sk-counter value from the list of sk-counter values ​​associated with the target candidate cell.

[0111] CLTM execution condition configuration For CLMT, in addition to LTM-related configurations, NW also provides LTM cell handover conditions or execution conditions for each candidate cell. In some example implementations, LTM cell handover conditions or execution conditions may include at least one of the following: One or more triggering conditions, or • An indication of whether the relationship between multiple triggering conditions is "AND" or "OR" (if more than one triggering condition is provided), that is, whether all or at least one of the multiple triggering conditions associated with the candidate cell needs to be met to trigger CLTM execution. For example, if the relationship is "AND", the UE should trigger CLTM execution if all triggering conditions associated with the candidate cell are met; while if the relationship is "OR", the UE should trigger CLTM execution if any one of the multiple triggering conditions associated with the candidate cell is met.

[0112] The triggering conditions for candidate cells for CLTM provided by NW may include at least one of the following information items: • L1 measurement ID, for example, used to identify the L1 measurement configuration that triggered the event; • L1 report configuration ID, for example, used to identify the L1 measurement configuration that triggered the event; • L3 measurement ID, for example, used to identify the L3 measurement configuration that triggered the event; • Event-triggered L1 measurement configuration, for example, including the threshold or offset value that must be used / met to trigger CLTM; • For CLTM execution to be triggered, specific criteria for the triggering event must be met within a certain timeframe. • The number of consecutive times the threshold / event needs to be met in order to trigger CLTM execution; • The number of beams / RS that need to be satisfied in order to trigger CLTM execution; • An indication of whether a combination of duration and number of times a threshold / event needs to be satisfied in order to trigger CLTM execution. For example, in order to trigger CLTM execution, the threshold / event needs to be satisfied N times within a specific / defined time period. Interaction / coordination regarding LTM-related IDs or cell sets Based on the LTM configuration described above, the NW can provide / configure IDs for each candidate cell or source serving cell to indicate specific UE behavior. These various IDs may include, for example: • The LTM candidate configuration ID mentioned above can be used to identify candidate cell configurations.

[0113] • The above-mentioned no-reset ID is called ltm-NoResetID. For example, the UE can use it to determine whether an L2 reset (e.g., PDCP data recovery, RLC reconstruction) should be performed when triggering an LTM cell handover process to an LTM candidate cell.

[0114] The aforementioned UE measurement TA ID, referred to as ltm-UE-MeasuredTA-ID, can be used by the UE to determine whether a UE-based TA measurement can be performed to obtain the TA of the indicated candidate cell.

[0115] The aforementioned security update ID, known as securityCellSetId, can be used by the UE to determine whether a security update should be performed when triggering an LTM cell handover process to an LTM candidate cell.

[0116] • TA group / set ID: The UE can use this to determine whether the TA of a candidate cell is the same as the TA of the source cell. The same TA group / set ID can be associated with the same TA.

[0117] These LTM-related IDs can be assigned / determined by the MN (e.g., serving MN CU) or the SN (e.g., candidate SN CU). These various IDs may or may not be assigned / determined by the same network node. For example, the no-reset ID, UE measurement TA ID, and / or TA group / set ID can be assigned / determined by the source or candidate SN, while the security update ID and / or LTM candidate configuration ID can be assigned / determined by the MN.

[0118] Regarding LTM candidate configuration IDs, in some example implementations of SCG LTM, if the LTM candidate configuration ID is set by the MN, the source or candidate SN (e.g., SN DU) may need to know the LTM candidate configuration ID for each candidate PSCell to trigger SCGLTM execution. For example, the LTM candidate configuration ID for the target candidate PSCell can be indicated in the cell handover command MAC CE. To coordinate LTM candidate configuration IDs between the MN and SN (e.g., the source SN or candidate SN), the following example options can be implemented: Option 1: The MN can send the mapping of LTM candidate configuration IDs to candidate cells to the SN, for example, through the SN add / modify request message.

[0119] Option 2: The MN can send a range of LTM candidate configuration IDs to the SN via, for example, an SN add / modify request message. The SN can then determine the LTM candidate configuration ID for each prepared candidate PSCell based on this ID range received from the MN. The SN can also send the prepared candidate PSCell information and the associated LTM candidate configuration ID to the MN via, for example, an SN add / modify request message.

[0120] Regarding LTM-related IDs or cell sets, in some implementations, an example process for transferring information about one or more LTM-related IDs or cell sets between the MN and SN (e.g., source SN or candidate SN) can be as follows: • In order for the MN to configure / set the cell set or LTM-related IDs for the current serving cell and / or each candidate cell, the SN may need to transmit at least one of the following information items to the MN via, for example, an SN Add / Modify Request Confirmation message or other Xn messages: ○ Mapping between candidate cells (e.g., referred to as LTM candidate configuration ID, candidate cell ID, or PCI+ frequency) and LTM-related IDs (e.g., no-reset ID, UE measurement TA ID, and / or TA group / set ID); ○ One or more candidate cells belonging to the same cell set, where cell handover between these cells does not require L2 reset (e.g., PDCP data recovery, RLC reconstruction). ○ One or more candidate cells belonging to the same cell set, where cell handover between these cells does not require a security update; or ○ One or more candidate cells belonging to the same cell set, where UE-based TA measurements can be performed; ○ One or more candidate cells belonging to the same cell set, where the TA value is the same; • The MN can determine / configure the LTM-related ID for the current serving cell and / or each candidate cell based on information received from the SN, for example.

[0121] In some example implementations, in order to properly trigger and / or execute SCG LTM, the LTM triggering node (e.g., SNDU or MN DU) may also need to know the LTM-related ID for each cell. For example: • If the SN is the triggering node, the MN can transmit the mapping between candidate cells (e.g., referred to as LTM candidate configuration ID, candidate cell ID, or PCI+ frequency) and LTM-related IDs to the SN through, for example, SN add / modify request confirmation messages or other Xn messages.

[0122] • The CU (e.g., MN CU or SN CU) can transmit the mapping between candidate cells and LTM-related IDs to the triggering DU (e.g., MN DU or SN DU) via, for example, UE context add / modify request messages or other F1 messages.

[0123] In some example implementations, the above instructions / information can be transmitted between MN and SN (or between CU and DU) using one of the following options: Option 1: Include the instruction / information directly in the Xn / X2 message or F1 message, for example, include the instruction / information as an information element.

[0124] Option 2: Include the indication / information in an RRC message (e.g., a CG-ConfigInfo or CG-Config message). This RRC message can be included as an information element in an Xn / X2 or F1 message.

[0125] SN's preparation process In some example implementations, SCG LTM or CLTM preparation can be initiated by the source SN or MN. This example procedure applies to, for example, SN / SCG / PSCell changes.

[0126] exist Figure 7 The example process of an inter-SN LTM or CLTM initiated by a source SN is shown. Figure 7 The interaction between UE 702, MNDU 704, MN CU 706, source SN DU 708, source SN CU 710, target SN CU 712, and target SN DU 714 is illustrated. Other candidate SNs may be involved, but are not shown. Figure 7 It is clearly shown in the text. Figure 7 Example procedures may include: 1. The source SN (e.g., source SN CU 710) initiates an inter-SN LTM or CLTM procedure by sending an SN change request message to the MN (e.g., MN CU 706), for example, based on an L3 measurement report from UE 702. This SN change request message may include at least one of the following information items: • An indication used to indicate that an LTM or subsequent LTM has been requested; • An indication used to indicate that a CLTM or subsequent CLTM has been requested; • One or more candidate SN IDs, for example, a list of candidate SN IDs; • One or more candidate cells recommended / recommended by the source SN, for example, a list of candidate cells recommended / recommended by the source SN (e.g., source SN CU 710) for each candidate SN; • The maximum number of candidate cells each candidate SN can prepare for LTM or CLTM; • SCG reference configuration (e.g., SCG reference cell configuration); • Measurements related to candidate SNs (e.g., layer 3 measurements); 2. The MN (e.g., MN CU 706) can request each candidate SN (e.g., target candidate SN CU 712 among the candidate SNs) to allocate resources for the UE through the SN addition procedure. The MN (e.g., MN CU 706) can send an SN addition request message to each candidate SN (e.g., target candidate SN CU 712). This message may include at least one of the following information items: • An indication used to indicate that an LTM or subsequent LTM has been requested; • An indication used to indicate that a CLTM or subsequent CLTM has been requested; • One or more candidate SN IDs, for example, a list of candidate SN IDs; • One or more candidate cells recommended / suggested by the source SN, for example, a list of candidate cells recommended / suggested by the source SN (e.g., source SN CU 710) for that candidate SN / each candidate SN; • The maximum number of candidate cells that a candidate SN can prepare for LTM or CLTM; • SN key for candidate SN (e.g., K SN ) and a list of associated sk-Counter values; • (One or more) requested / recommended LTM candidate configuration IDs or ID ranges for candidate cells; • A list of LTM candidate configuration ID mappings, used to indicate, for example, the mapping between candidate cells (one or more) and LTM candidate configuration IDs (one or more); • Request indication for SCG reference configuration; • SCG reference configuration (if a generated reference configuration exists); • L1 RS measurement configuration request indication. This indication can specify whether an SSB configuration, CSI-RS configuration, or both are requested. • Early TA request instructions to obtain resource configuration; or • A request indication for the TCI status configuration of (one or more) candidate cells.

[0127] 3. In the cell list suggested by the source SN (e.g., source SN CU 710), the candidate SN (e.g., target SN CU 712) can determine the list of candidate cells / PSCells to be prepared for LTM or CLTM by considering the maximum number of candidate cells to be prepared as indicated by the MN in step 2 above. For each prepared candidate PSCell, the candidate SN (e.g., target SN CU 712) prepares LTM-related configurations, such as the SCG radio resource configuration for the corresponding candidate PSCell. For example, for each prepared candidate PSCell, the candidate SN CU can initiate a UE context establishment procedure to the candidate SN DU (e.g., target SN DU 714) to request the candidate SN DU to generate LTM-related low-layer configurations. For example, the candidate SN CU (e.g., target SN CU 712) can send a UE context establishment request message to the candidate DU (e.g., target SN DU 714). This message may include the information included in the SN add request message in step 2 above.

[0128] 4. If a candidate SN DU (e.g., target SN DU 714) accepts a request for LTM or CLTM preparation, it responds to a UE context establishment response message to a candidate SN CU (e.g., target SN CU 712). This message includes the LTM-related low-layer configurations generated for the accepted candidate cell (e.g., cell group configuration (contained in, for example, a CellGroupConfig IE), L1 RS measurement configuration, early TA acquisition resource configuration, and TCI state configuration). The L1 RS measurement configuration, early TA acquisition resource configuration, and / or TCI state configuration can be provided in individual IEs (e.g., excluding the container containing CellGroupConfig).

[0129] 5. The candidate SN (e.g., target SN CU 712) may send an SN add request confirmation message to the MN (e.g., MN CU 706) in response to the SN add request in step 2. This SN add request confirmation message may include at least one of the following information items: • One or more prepared candidate SN DU IDs; • One or more prepared candidate cell IDs, for example, for each candidate SN DU, a list of prepared candidate cell IDs belonging to that DU; • PCI information for each prepared candidate cell; • The corresponding SCG configuration for each prepared candidate cell (e.g., included in the RRC reconfiguration message); • An indicator used to indicate whether the candidate cell configuration is a complete configuration relative to the SCG reference configuration; • SSB configuration, for example, for L1 measurement or TCI status configuration; • CSI-RS configuration, for example, for L1 measurement or TCI status configuration; • Early UL synchronization configuration, such as early RACH configuration; • TCI status configuration, such as DL or combined TCI status list, or UL TCI status list.

[0130] The SSB configuration, CSI-RS configuration, early UL synchronization configuration, and / or TCI status configuration listed above can be provided for each prepared candidate cell or for all prepared candidate cells within a candidate SN.

[0131] If the SN add request message includes a request indication for the SCG reference configuration, the candidate SN may also include the generated SCG reference configuration in the SN add request confirmation message.

[0132] If the SN add request message includes an indication to request CLTM or subsequent CLTM, the candidate SN may also include the following information in the SN add request confirmation message: for each prepared candidate cell, (i.e., the list of candidate cells for subsequent CLTM applied when the candidate cell becomes the current serving cell) and the associated execution conditions. In addition, Figure 7 In 5a, the MN (e.g., MN CU 706) can send an Xn-U address indication message to candidate SNs (e.g., target SN CU 712 and other candidate SNs) to provide information for data forwarding and / or trigger early data forwarding. For example, for SN terminal bearers using MCG resources, the MN can provide Xn-U DL TNL (Transport Network Layer) address information in this message.

[0133] 6. The MN (e.g., MN CU 706) can initiate an SN modification process to the source SN (e.g., source SN CU 710 / source SN DU 708), as shown in the dashed box in step 6, to notify the source SN of the prepared candidate PSCell information. Based on the candidate PSCell information received from the candidate SN, the source SN can generate L1 measurement-related configurations (e.g., CSI resource configuration, L1 measurement report configuration) for the candidate PSCell. The MN can also initiate an SN modification process to each candidate SN to notify the source SN of candidate PSCell information prepared by other candidate SNs, such as... Figure 7The dashed box below the dashed box surrounding step 6 is shown. A candidate SN can generate L1 measurement-related configurations and / or update the candidate SCG configurations of candidate PSCells belonging to that candidate SN, for example, for subsequent SCGLTM or CLTM.

[0134] For example, such as Figure 7 As shown in 6a, the MN (e.g., MN CU 706) can send an SN modification request message to the source SN (e.g., source SN CU 710). Similarly, the MN can send an SN modification request message to the candidate SN (as shown in the dashed box below step 6). This SN modification message may include at least one of the following information items: • One or more candidate SN IDs, for example, a list of candidate SN IDs; • One or more candidate SN DU IDs, for example, for each candidate SN, a list of candidate DUIDs belonging to that candidate SN; • One or more prepared candidate PSCell IDs, for example, a list of prepared candidate PSCell IDs for each candidate SN or candidate SN DU; • The LTM candidate configuration ID of the prepared candidate PSCell; • The mapping between the prepared candidate PSCells and LTM-related IDs, for example, the mapping described above; • Prepare the L1 RS (e.g., SSB and / or CSI-RS) configuration for the candidate PSCell; • Prepare early UL synchronization configurations for candidate PSCells; • Prepare the TCI status configuration for the candidate PSCell; • SCG reference configuration; • CSI resource configuration, for example, L1 measurement for candidate PSCells; Furthermore, in Figure 7 In section 6b, the source SN CU (e.g., source SN CU 710) can send a UE context modification request message to the source SN DU 708. This message may include the CSI resource configuration, TCI status information, early UL synchronization configuration, and / or LTM candidate configuration ID of the candidate cells in other candidate nodes. The source SN CU 710 may also provide a reference configuration to the source SN DU.

[0135] Furthermore, in 6c, the source SN DU 708 can respond to the source SN CU 710 with a UE context modification response message. This message may include updated candidate configurations for candidate PSCells, such as L1 measurement report configurations.

[0136] Furthermore, in 6d, in response to the SN modification request message, the source SN CU 710 can send an SN modification request confirmation message to the MN CU 706. This message may include at least one of the following information items: • CSI resource configuration, for example, L1 measurement for candidate PSCells; • Updated SCG configuration for the current serving cell or candidate PSCell, including, for example, L1 measurement report configuration. The CSI resource configuration for L1 measurements of candidate PSCells can be generated by the MN or the source SN based on, for example, the L1 RS configuration of the received candidate PSCell.

[0137] Steps 6a to 6d above apply to the interaction between MN CU 706 and each of the candidate SNs (one or more) in the form of SN modification request, UE context modification request, UE context modification response and SN addition request confirmation, as shown in the dashed box below step 6.

[0138] In some example implementations, during an SN modification process to a source SN (e.g., source SN CU 710), the source SN can generate a CSI resource configuration for L1 measurements of the candidate PSCell. The source SN can send the CSI resource configuration to the MN via an SN modification response message. The MN can then transmit the generated CSI resource configuration to the candidate SN via the SN modification process to the candidate SN.

[0139] 7. The MN (e.g., MN CU 706) may send an RRC reconfiguration message to the UE 702, which includes an LTM or CLTM configuration (or an LTM-related configuration). The LTM configuration may include a list of LTM candidate configurations. The CLTM configuration may include a list of LTM candidate configurations and execution conditions for each candidate. The RRC reconfiguration message may also include an updated source SCG configuration (included in the RRC reconfiguration message generated by the source SN), for example, to provide an L1 measurement report configuration.

[0140] 8. UE 702 may respond to an RRC reconfiguration complete message to the MN (e.g., MN CU 706). This MN RRC reconfiguration complete message may include an SN RRC reconfiguration complete message for the source SN.

[0141] 9. The MN (e.g., MN CU 706) may send an SN change confirmation message to the source SN (e.g., source SN CU 710) to indicate that SCG LTM or CLTM has been prepared. Source SNs 708 and 710 may continue to provide user data to UE 702. If the RRC reconfiguration completion message includes an SN RRC response message, the MN (e.g., MN CU 706) may notify the source SN (e.g., source SN CU 710) of the SN RRC reconfiguration completion message via the SN change confirmation message.

[0142] 10. Source SN CU 710 can send a notification message to source SN DU 708 via, for example, an F1 message, to indicate / notify that SCG LTM or CLTM has been prepared. This notification message may include a mapping between prepared candidate cells and LTM-related IDs, such as the mapping described above.

[0143] MN-initiated preparation process exist Figure 8 The example procedure for an MN-initiated inter-SN LTM or CLTM is shown. This example procedure is applicable to, for example, SN / SCG / PSCell additions or SN / SCG / PSCell changes. Figure 8 Example interactions are shown between UE 802, current MN DU 804, current MN CU 806, source SN DU 808, source SN CU 810, target SN CU 812, and target SN DU 814. Other candidate SNs may be involved, but are not shown. Figure 8 It is clearly shown in the text. Figure 8 Example procedures may include: 1. The MN (e.g., MN CU 806) may, for example, initiate an inter-SN SCG LTM or CLTM by requesting a candidate SN (e.g., target SN CU 812) to allocate resources to the UE via an SN addition procedure, based on an L3 measurement report from the UE 802. The MN (e.g., MN CU 806) may send an SN addition request message to each candidate SN (e.g., target SN CU 812). This message may include... Figure 7 The information items described in step 2. The message may also include information related to candidate cells recommended / suggested by MN (e.g., MN CU 806) based on measurement results.

[0144] 2 to 7. These steps are similar to Figure 7 Steps 3 to 8 in the process.

[0145] 8. If the RRC reconfiguration complete message includes an SN RRC response message, the MN (e.g., MN CU 806) can notify the source SN of the SN RRC reconfiguration complete message via, for example, the SN reconfiguration complete message.

[0146] 8a. After receiving the RRC reconfiguration complete message from the UE, the MN (e.g., MN CU 806) notifies the source SN (e.g., source SN CU 810) that LTM has been configured via, for example, an Xn-U address indication procedure. The source SN (e.g., MN CU 806) may also initiate an early state transfer procedure and / or begin early data forwarding. PDCP SDU (Service Data Unit) forwarding may occur during early data forwarding.

[0147] 9. This step is similar to Figure 7 Step 10 in the process.

[0148] In some example implementations, such as in an MN-initiated inter-SN LTM for SN / SCG / PSCell addition, the aforementioned S-SN CU and S-SN DU may not be involved, and Figure 8 In this process, steps involving S-SN CU / DU can be ignored / skipped, and other steps are applicable.

[0149] Early synchronization and LTM cell handover execution / completion Figure 5 Steps 4 through 8, the early synchronization process (referred to as the synchronization process), the LTM cell handover execution process, and the LTM cell handover completion process, are generally applicable to various types of LTM, including SCG LTM or CLTM. The specific example implementations below are applicable to either or both of SN-initiated SCG LTM / CLTM and / or MN-initiated SCG LTM / CLTM.

[0150] For example, the early synchronization process and / or SCG LTM cell handover execution / completion process can be triggered by the MN (e.g., MNDU) or the SN (e.g., source / candidate SN DU), depending on whether the L1 measurement configuration is generated by the MN or the SN, and / or whether the L1 measurement results are reported by the UE to the MN or the SN.

[0151] For example, for SCG CLTM, the SCG LTM cell handover execution / completion process can be triggered by the UE based on whether one or more execution conditions of the candidate cell are met.

[0152] In some example implementations, the early synchronization process and / or SCG LTM cell handover execution / completion process can be triggered by the SN. For example, if the L1 measurement configuration (e.g., referred to as the SCG L1 measurement configuration) is generated / provided by the SN, the UE can send an L1 measurement report to the SN (e.g., the source / candidate SN DU). Based on the L1 measurement results of the candidate cell, the SN can trigger the early synchronization process and / or SCG LTM cell handover execution process, including, for example, an SN-triggered early synchronization process and / or SCG LTM cell handover execution process.

[0153] In some example implementations of the early synchronization process triggered by the SN and / or the SCG LTM cell handover execution / completion process, the SN (e.g., the source SN) may determine the target candidate cell for SCG LTM execution based on the L1 measurement report and send a cell handover command MAC CE to the UE to trigger the execution of SCG LTM.

[0154] In some other example implementations of the early synchronization process triggered by the SN and / or the SCG LTM cell handover execution / completion process, the SN (e.g., the source SN) may trigger an early synchronization process to a candidate cell based on, for example, L1 measurements of the candidate cell, before sending the cell handover command MAC CE to the UE. For example, the SN may initiate an early RACH process triggered by a PDCCH command to obtain the TA of the candidate cell. As another example, the SN may activate the TCI state of one or more candidate cells different from the currently serving cell before sending the cell handover command MAC CE to the UE.

[0155] In some other example implementations, the early synchronization process and / or SCG LTM cell handover execution / completion process can begin from the MN instead of the SN, generate an L1 measurement configuration (e.g., called an MCG L1 measurement configuration), and the UE reports the L1 measurement report to the MN (e.g., MNDU) instead of the SN. In this case, two example options can be implemented to trigger the early synchronization process and / or SCG LTM cell handover execution process.

[0156] In the first option, the MN can trigger an early synchronization procedure and / or an SCG LTM cell handover execution procedure based on, for example, L1 measurement results of a candidate cell. For example, the MN (e.g., MN DU) can determine the target candidate cell for SCG LTM execution and, based on, for example, an L1 measurement report, send a cell handover command (MAC CE) to the UE to trigger SCG LTM execution. Alternatively, the MN (e.g., MN DU) can trigger an early synchronization procedure to a candidate cell based on, for example, L1 measurement results of a candidate cell before sending the cell handover command (MAC CE) to the UE. For example, the MN (e.g., MN DU) can initiate an early RACH procedure triggered by a PDCCH command to obtain the TA of a candidate cell. Alternatively, the MN (e.g., MN DU) can activate the TCI state of one or more candidate cells different from the currently serving cell before sending the cell handover command (MAC CE) to the UE.

[0157] In the second option, the MN can transmit the received L1 measurement results to the SN (e.g., the source SN DU). Based on the L1 measurement results of the candidate cell, the SN can trigger an early synchronization process and / or an SCG LTM cell handover execution process, for example, as triggered by the SN.

[0158] In some example implementations, LTM-related signaling / commands (e.g., LTM cell handover command MAC CE, candidate cell TCI state activation / deactivation MAC CE, DCI for early RACH triggered by PDCCH command) can be enhanced to distinguish whether these LTM-related signaling / commands are applicable to MCG LTM or SCG LTM. At least the following two example options can be considered.

[0159] In the first option for distinguishing between signaling and commands, an indicator / flag can be introduced in the signaling / command to indicate whether the signaling / command is applicable to MCG or SCG. For example, if the indicator is set to 0 (or 1), the signaling / command is indicated for MCG LTM; while if the indicator is set to 1 (or 0), the signaling / command is indicated for SCG LTM.

[0160] For example, this indicator / flag can be introduced in the LTM cell handover command MAC CE. If the indicator is set / indicated for SCG, the UE can perform at least one of the following operations: (1) consider the information in the received MAC CE to be for SCG LTM; (2) indicate to the upper or lower layer that the LTM cell handover process is triggered for SCG; (3) perform LTM-related operations in the SCG MAC layer, including, for example, MAC reset, TA processing, configuring uplink grant selection, and RACH-free LTM cell handover. If the indicator is set / indicated for MCG, the UE can perform at least one of the following operations: (1) consider the information in the received MAC CE to be for MCG LTM; (2) indicate to the upper or lower layer that the LTM cell handover process is triggered for MCG; (3) perform LTM-related operations in the MCG MAC layer, including, for example, MAC reset, TA processing, configuring uplink grant selection, and RACH-free LTM cell handover.

[0161] For example, this indicator / flag can be introduced in the candidate cell TCI state activation / deactivation MAC CE. If the indicator is set / indicated for SCG, the UE can perform at least one of the following operations: (1) consider the information in the received MAC CE to be for SCG LTM; (2) indicate to the lower layer that the information in the MAC CE is for SCG. If the indicator is set / indicated for MCG, the UE can perform at least one of the following operations: (1) consider the information in the received MAC CE to be for MCG LTM; (2) indicate to the lower layer that the information in the MAC CE is for MCG.

[0162] For example, this indicator / flag can be introduced in the DCI used for early RACH triggered by a PDCCH command. If the indicator is set / indicated for SCG, the UE can perform at least one of the following operations: (1) consider the information in the received DCI to be used for early RACH triggered by a PDCCH command at SCG; (2) perform early RACH triggered by a PDCCH command at SCG MAC, for example, send a preamble to the indicated candidate cell at SCG MAC. If the indicator is set / indicated for MCG, the UE can perform at least one of the following operations: (1) consider the information in the received DCI to be used for early RACH triggered by a PDCCH command at MCG; (2) perform early RACH triggered by a PDCCH command at MCG MAC, for example, send a preamble to the indicated candidate cell at MCG MAC.

[0163] In the second option for distinguishing signaling / commands, the UE can determine whether the received signaling / command is for the MCG or SCG based on the candidate cell ID (e.g., LTM candidate configuration ID) indicated in the corresponding signaling / command. For example, if the indicated candidate cell ID is for a candidate PSCell or SCG LTM, the UE can assume that the information in the received signaling / command is for the SCG, and / or can perform the corresponding operation at the SCG (as described above). If the indicated candidate cell ID is for a candidate PCell or MCG LTM, the UE can assume that the information in the received signaling / command is for the MCG, and / or can perform the corresponding operation at the MCG (as described above).

[0164] When an LTM cell handover is triggered (as described above, initiated by the MN or source SN), the target node may need to be notified to perform the LTM cell handover. For example, when an LTM cell handover is triggered, the triggering node (e.g., the MN or source SN) may need to notify the target node (e.g., the target SN) of the target cell information of the selected / indicated target candidate cell so that, for example, the target SN can begin transmission / scheduling with the UE, such as dynamic UL authorization scheduling for the UE in the absence of RACH LTM.

[0165] The target cell information above / below may include at least one of the following: target cell ID (e.g., the LTM candidate configuration ID of the target cell), the selected TCI status ID of the target cell, or the beam / RS ID.

[0166] Regarding notifying the target cell information to the target SN, two example options can be implemented.

[0167] In the first option of notifying the target cell information to the target SN, when transmitting a cell handover command to the UE, the triggering node (MN or source SN) can send a notification message (e.g., a cell handover notification message) to the target SN to indicate the target cell information. If the triggering node is the source SN, the source SN can send this information to the MN, and then the MN can transmit the received information to the target SN. If there is a direct connection between the source SN and the target SN, the SN can directly transmit the received information to the target SN.

[0168] In the second option of notifying the target cell information to the target SN, upon triggering an LTM cell handover (e.g., receiving an LTM cell handover command from the NW, or meeting the execution conditions of the target candidate cell), the UE can send an RRC reconfiguration complete message to the MN. This message may include the target cell information. The MN can then transmit the received target cell information to the target SN.

[0169] In some example implementations, the first and second options described above regarding notifying the target cell information to the target SN can be used in combination.

[0170] exist Figure 9 The following is shown in Figure 5 The general principles and the example SN-triggered early synchronization process and / or SCG LTM cell handover execution process described above involve UE 902, MN DU 904, MN CU 906, source SN DU 908, source SN CU 910, and various candidate SN CUs and candidate SN DUs. Figure 9 Only target SN CU 912 and target SN DU914 are explicitly shown in the text, thus indicating further detailed example interactions within each of the MN, source SN and target SN (e.g., between their CU and DU in the case of CU-DU separation). Figure 9 An example process may include the following example steps: 1. UE 902 may perform DL synchronization with candidate PSCell before receiving cell handover command, based on a TCI state activation command (e.g., via candidate cell TCI state activation / deactivation MAC CE) from, for example, the source SN (e.g., source SN DU908).

[0171] 2. If indicated by the NW, UE 902 may perform UL synchronization with the candidate PSCell before receiving the cell handover command (e.g., early RACH triggered by a PDCCH command based on the UE's TA measurement). Taking early RACH triggered by a PDCCH command as an example, in 2a to 2f: 2a. The source SN (e.g., source SN DU 908) may (e.g., via DCI) send Random Access (RA) indication signaling to trigger an early RACH to the target cell to obtain a TA. This signaling may include a candidate cell indicator (e.g., LTM candidate configuration ID), an RA preamble index, an UL (Uplink) / SUL (Supplementary Uplink) indicator, an SSB index, a PRACH (Physical Random Access Channel) mask index, and / or a PRACH retransmission indicator. The signaling may also include an indicator indicating that the RA procedure is performed for the SCG (e.g., at the SCG MAC).

[0172] 2b. UE 902 may send a preamble to the target SN of the indicated candidate cell (e.g., target SN DU 914).

[0173] 2c. The target SN (e.g., target SN DU 914) can calculate the TA value of the indicated candidate cell based on, for example, a received preamble. Target SN DU 914 can send a list of TA-related information items to target SNCU 912 via an F1 message (e.g., a DU-CU TA information transmission message). The TA-related information may include the TA value, associated RA resource information (e.g., preamble index, RA-RNTI (Random Access Radio Network Temporary Identifier)), candidate cell ID, and / or DU ID (e.g., source SN DU ID or candidate SN DU ID).

[0174] 2d / 2e. A target SN (e.g., target SN CU 912) can send received TA-related information (e.g., from one or more associated target SNs DU) to an MN (e.g., MN CU 906) via Xn messages (e.g., TA information transmission messages). An MN (e.g., MN CU 906) can transmit received TA-related information to a source SN (e.g., source SN CU 910) via Xn messages (e.g., TA information transmission messages). In some example implementations, if a direct connection exists between the source SN and the target SN, the target SN can directly send TA-related information to the source SN via Xn messages (e.g., TA information transmission messages).

[0175] 2f. The source SN CU 910 can transmit the received TA-related information to the source SN DU 908 via an F1 message (e.g., CU-DU TA information transmission message).

[0176] 3. UE 902 may perform L1 measurements on (one or more) configured candidate cells and / or transmit L1 measurement reports to the source SN (e.g., source SN DU 908).

[0177] 4. The source SN (e.g., source SN DU 908) can determine whether to perform LTM cell handover to the target cell. The source SN can consider the following options to determine LTM triggering: Option 1: The source SN DU 908 can automatically determine whether to trigger LTM execution based on, for example, the received L1 measurement value; Option 2: Source SN DU 908 can coordinate with source SN CU 910 to determine when to trigger LTM execution. For example, source DU 908 can (e.g., based on L1 measurements) determine or request to trigger LTM execution and send information about the selected / requested candidate target cell (e.g., target cell ID, LTM candidate configuration ID of the target cell, and / or TCI status / beam / RS information of the target cell) to source CU 910 via an F1 message. Source SN CU 910 can (e.g., considering load balancing) accept or reject the selected / requested candidate target cell and send a response message to source SN DU 908 via an F1 message. If source SN CU rejects the selected / requested candidate target cell, the response message may include a reason value to indicate the reason for rejection (e.g., overload).

[0178] Option 3: The source SN can coordinate with the MN to determine when to trigger LTM execution. For example, source SN DU 908 can (e.g., based on L1 measurements) determine or request to trigger LTM execution and send information about selected / requested candidate target cells to source SN CU 910. Source SN CU 910 can transmit the received information to the MN (e.g., MN CU 906). MN CU 906 can accept or reject the selected / requested candidate target cells and send a response message to the source SN via an Xn message. Source SN CU 910 can then notify source SN DU 908 of the response. If MN CU rejects the selected / requested candidate target cell, the response message may include a reason value to indicate the reason for rejection (e.g., overload).

[0179] Option 4: The source SN can coordinate with the target SN to determine whether to trigger LTM execution. For example, source SN DU 908 can (e.g., based on L1 measurements) determine or request to trigger LTM execution and send information about selected / requested candidate target cells to source SN CU 910. Source SN CU 910 can transmit the received information to the target SN via MN. The target SN (e.g., target SN CU or target SN DU) can accept or reject the selected / requested candidate target cells and send a response message to the source SN via MN. Source SN CU 910 can notify source SN DU 908 of the response. If target SN CU rejects the selected / requested candidate target cell, the response message can include a reason value to indicate the reason for rejection (e.g., overload). In some examples, if a direct connection exists between the source SN and the target SN, the source SN can coordinate directly with the target SN via Xn messages without the involvement of MN as an intermediary.

[0180] 5. The source SN (e.g., source SN DU 908) can transmit a cell handover command (e.g., cell handover command MACCE) that triggers a cell handover by including a candidate configuration index of the target cell (e.g., referred to as LTM candidate configuration ID minus 1). The UE can hand over to the target cell and apply the corresponding configuration indicated by the candidate configuration index. The cell handover command may also include an indicator to indicate whether the LTM cell handover is for an SCG or a candidate PSCell.

[0181] 6. The source SN can initiate a cell handover notification procedure to notify the MN and / or the target SN of target cell information. Target cell information may include at least one of the following: target cell ID (e.g., the target cell's LTM candidate configuration ID), selected TCI state ID, or the target cell's beam / RS ID. For example: 6a. Source SN DU 908 may send a notification message (e.g., DU-CU cell handover notification message) to source SN CU 910 to indicate that LTM has been initiated / triggered for the UE. This message may include target cell information.

[0182] 6b / 6c. The source SN CU 910 can transmit received target cell information to the MN (e.g., MN CU 906), and the MN can then transmit the received information to the target SN (e.g., target SN CU 912) via an Xn message (e.g., a cell handover notification message). In some example implementations, if a direct connection exists between the source SN and the target SN, the source SN can directly notify the target SN via an Xn message without the involvement of the MN.

[0183] 6d. The target SN CU 910 can send the received information to the target SNDU 914 via an F1 message (e.g., CU-DU cell handover notification message).

[0184] 7. After the UE detaches from the source SN and applies the target SN configuration, the UE 902 may send an MN RRC reconfiguration complete message to the MN CU and / or DU 904 and 906. This message may include target cell information, such as the target cell ID, the selected / indicated TCI state ID, or the target cell's beam / RS ID. If a new sk-Counter value has been selected / applied, the message may also include the sk-Counter value associated with the target cell.

[0185] 8. The MN (e.g., MN CU 906) can notify the target SN (e.g., target SN CU 912) that the UE has successfully completed the reconfiguration process for the target cell via an Xn message (e.g., SN reconfiguration complete message or SN change confirmation message). This message may include target cell information and / or the associated sk-counter value (if received via the MN RRC reconfiguration complete message).

[0186] 9. If the UE does not have a valid TA for the target cell, UE 902 may perform a random access procedure to the target cell. If the UE has a valid TA for the target cell, the UE skips the random access procedure to the target cell, for example, performing LTM without RACH. If the UE performs the RA procedure, the UE can consider the LTM cell handover execution to be successfully completed when the random access procedure is successfully completed. For LTM without RACH, the UE can consider the LTM cell handover execution to be successfully completed when it determines that the network has successfully received its first UL data.

[0187] Similarly, in Figure 10 The following is shown in Figure 5 The general principles and the example MN-triggered early synchronization process and / or SCG LTM cell handover execution process described above involve UE 1002, MN DU 1004, MN CU 1006, source SN DU 1008, source SN CU 1010, and various candidate SN CUs and candidate SN DUs, of which only target SN CU 1012 and target SN DU 1014 are explicitly shown. Therefore, Figure 10 Further detailed example interactions are indicated within each of the MN, source SN, and target SN (e.g., between their CUs and DUs in the case of CU-DU separation). Figure 10 An example process may include the following example steps: 1. UE 1002 may perform DL synchronization with candidate PSCell based on a TCI state activation command, for example, from MN (e.g., MN DU 1004), before receiving a cell handover command.

[0188] 2. If indicated by the NW, UE 1002 can perform UL synchronization with the candidate PSCell before receiving the cell handover command (e.g., early RACH triggered by a PDCCH command based on the UE's TA measurement). Taking early RACH triggered by a PDCCH command as an example: 2a. The MN (e.g., source MN DU 904) may (e.g., via DCI) send RA indication signaling to trigger an early RACH to the target cell to obtain a TA. This signaling may include a candidate cell indicator (e.g., candidate cell configuration ID), an RA preamble index, a UL / SUL indicator, an SSB index, a PRACH mask index, and / or a PRACH retransmission indicator. The signaling may also include indicators indicating that the RA procedure is directed to the SCG, for example, performed at the SCG MAC.

[0189] Steps 2b to 2d are similar to... Figure 9 Steps 2b to 2d in the above.

[0190] 2e. MN CU 1006 can transmit the received TA-related information to MN DU 1004 via F1 messages (e.g., CU-DU TA information transmission messages).

[0191] 3. UE 1002 can perform L1 measurements on the configured candidate cells and / or send L1 measurement reports to MN (e.g., MN DU 1004).

[0192] 4. The MN (e.g., source MN DU 1004) can determine whether to perform an LTM cell handover to the target cell. The MN can consider the following example options to determine LTM triggering: Option 1: The source MN DU 1004 can automatically determine whether to trigger LTM execution based on, for example, the received L1 measurement; Option 2: MN DU 1004 can coordinate with MN CU 1006 to determine when to trigger LTM execution. For example, MN DU 1004 can (e.g., based on L1 measurements) determine or request to trigger LTM execution and send information about the selected / requested candidate target cell (e.g., target cell ID, LTM candidate configuration ID of the target cell, and / or TCI status / beam information of the target cell) to MN CU 1006 via an F1 message. MN CU 1006 can (e.g., considering load balancing) accept or reject the selected / requested candidate target cell and send a response message to MN DU 1004 via an F1 message. If MN CU rejects the selected / requested candidate target cell, the response message may include a reason value to indicate the reason for rejection (e.g., overload).

[0193] Option 3: The MN can coordinate with the target SN to determine when to trigger LTM execution. For example, MN DU 1004 can (e.g., based on L1 measurements) determine or request to trigger LTM execution and send information about selected / requested candidate target cells to the source MN CU 1006. MN CU 1006 can transmit the received information to the target SN CU 1012. The target SN (e.g., target SN CU or target SN DU) can accept or reject the selected / requested candidate target cells and send a response message to the MN. MN CU 1006 can notify the source MN DU 1004 of the response. If the target SN rejects the selected / requested candidate target cell, the response message can include a reason value to indicate the reason for rejection (e.g., overload).

[0194] 5. The MN (e.g., MN DU 1004) can send a cell handover command (e.g., cell handover command MAC CE) that triggers a cell handover by including a candidate configuration index of the target cell (e.g., referred to as LTM candidate configuration ID minus 1). The UE 1002 can hand over to the target cell and apply the configuration indicated by the candidate configuration index. The cell handover command may also include an indicator to indicate whether the LTM cell handover is for an SCG or a candidate PSCell.

[0195] 6. The MN can initiate a cell handover notification procedure to notify the target SN of target cell information. Target cell information may include at least one of the following: target cell ID (e.g., the target cell's LTM candidate configuration ID), the selected TCI state ID of the target cell, or the beam / RS ID. For example: 6a. MN DU 1004 may send a notification message (e.g., DU-CU cell handover notification message) to MN CU 1006 to indicate that LTM has been initiated / triggered for the UE. This message may include target cell information.

[0196] 6b. MN CU 1006 can transmit the received target cell information to the target SN CU 1012 via Xn messages (e.g., cell handover notification messages).

[0197] 6c. The target SN CU 1012 can send the received target cell information to the target SNDU 1014 via an F1 message (e.g., a CU-DU cell handover notification message).

[0198] 7 to 9. These steps are similar to Figure 9 Steps 7 to 9 in the process.

[0199] In some example implementations, not all steps in the flowchart need to be executed. For example, Figure 10The steps (one or more) within the dashed box can be performed as optional steps. For example, for an MN-initiated inter-SN LTM added for SN / SCG / PSCell, S-SN CU and S-SN DU may not be involved, and... Figure 10 The steps involving S-SN CU / DU can be ignored / skipped, and the other steps still apply.

[0200] The above example procedure can also be applied to SCG CLTM. For SCG CLTM, Figure 9 or Figure 10 Steps 3 through 5 can be ignored / skipped. Instead, after receiving the CLTM configuration, the UE maintains a connection with the source SN and begins evaluating the execution conditions of the CLTM candidate cells. If at least one CLTM candidate cell meets the corresponding execution conditions, the UE selects a candidate cell to perform an LTM cell handover, for example, separating from the source cell, and applies the stored corresponding configuration to the selected candidate cell (e.g., the target cell). If the UE does not have a valid TA for the target cell, the UE performs a random access procedure to the target cell. If the UE has a valid TA for the target cell, the UE performs a RACH-free cell handover to the target cell.

[0201] Overall Process - SN-Initiated Inter-SN LTM / CLTM Based on the various examples implemented above, Figures 11 to 12 The document illustrates a sample overall procedure for an inter-SN LTM / CLTM initiated by an SN, involving UE 1102, MN 1104, source SN 1106, candidate SNs (including, for example, target potential SN 1108 and another potential target or candidate SN 1110), UPF (User Plane Function) 1112 or the core network, and AMF (Access and Mobility Management Function) 1114 or the core network. This sample procedure is applicable to, for example, SN / SCG / PSCell changes. Figures 11 to 12 A general example process for LTM / CLTM initiated by the SN can include: 1. Source SN 1106 can initiate an inter-SN LTM / CLTM process by sending an SN change request message to MN 1104.

[0202] 2. MN 1104 can request each candidate SN (e.g., SN 1108 or 1110) to allocate resources for the UE through the SN addition procedure, corresponding to Figure 7 Step 2.

[0203] 3. In the cell list recommended by the MN (included in the request sent by the MN to the candidate SN in step 2), candidate SN 1108 or 1110 determines the list of PSCells to be prepared for LTM by considering (e.g., the maximum number of candidate cells to be prepared as indicated by the MN in the request in step 2). For each prepared PSCell, the candidate SN provides the corresponding SCG radio resource configuration and sends this information to MN 1104 via an SN Add Request Acknowledgment message, corresponding to... Figure 7 Step 5.

[0204] 3a. MN 1104 may send Xn-U address indication messages to candidate SNs 1108 and 1110 to provide information for data forwarding and / or trigger early data forwarding (e.g., from the source SN to (one or more) target / candidate SNs). For example, for SN terminal bearers using MCG resources, MN 1104 may provide Xn-U DL TNL address information in this message.

[0205] 4. MN 1104 can initiate an SN modification process for source SN 1106 and / or candidate SNs 1108 and / or 1110 to notify the SNs of the prepared candidate PSCell information and / or to allow the SNs to generate L1 measurement-related configurations (e.g., CSI resource configuration, L1 measurement report configuration), corresponding to... Figure 7 Step 6.

[0206] 5 to 8. These steps are similar to Figure 7 Steps 7 through 9 in the process include, for example, MN 1104 communicating with UE 1102 regarding the LTM configuration and / or the updated source SCG configuration. UE 1102 responds to MN 1104. Furthermore, MN 1104 communicates with source SN 1106 to notify the source SN that LTM / CLTM preparation is complete.

[0207] 8a. If early data forwarding is applied, MN 1104 can notify source SN 1106 of the data forwarding address received from the candidate SN via, for example, an Xn-U address indication message. If applicable, source SN 1106 can begin early data forwarding to the target / candidate SN along with the early state transfer process. PDCP SDU forwarding can be performed during early data forwarding. If multiple candidate SNs 1108 and 1110 are prepared, MN 1104 can provide source SN 1106 with a list of target / candidate SN IDs and a list of data forwarding addresses.

[0208] 9a to 9b. These steps are similar to Figure 9 Steps 1 to 2 are used for DL ​​and UL synchronization.

[0209] 10 to 15. These steps are similar to Figure 9 Steps 3 to 9 of the LTM / CLTM execution process are described in the text.

[0210] 16. If source SN 1106 is configured as a candidate SN (e.g., for subsequent LTM / CLTM), MN 1104 may trigger an MN-initiated SN modification procedure to notify the source SN to stop providing user data to the UE in order to switch to a ready state, and / or, if applicable, allow configuration of a new data forwarding address. If source SN 1106 is not configured as a candidate SN, MN 1104 may instead trigger an MN-initiated SN release procedure to notify source SN 1106 to stop providing user data to the UE.

[0211] 17. If applicable, MN 1104 may trigger the Xn-U address indication process to notify source SN 1106 of the address of the SN of the selected candidate PSCell to begin subsequent data forwarding.

[0212] 18a / b. If the PDCP endpoint changes for a bearer using RLC AM (Radio Link Control Acknowledged Mode), the source SN sends an SN status transmission message, and the MN then sends that SN status transmission message to the SN of the selected / target candidate PSCell if necessary.

[0213] 19. If applicable, perform the update of the UP path to the core network via the PDU session path update procedure.

[0214] 20. If source SN 1106 is not configured as a candidate SN (e.g., for subsequent SCG LTM / CLTM), MN 1104 can send a UE context release message to source SN 1106 after the path update procedure is completed. Source SN 1106 can then release the radio resources and C-plane (control plane) related resources associated with the UE context. Any ongoing data forwarding can continue.

[0215] Overall Process - MN-Initiated Inter-SN LTM / CLTM Further, based on the various examples mentioned above, in Figures 13 to 14The document illustrates a sample overall procedure for an inter-SN LTM / CLTM initiated by the MN, involving UE 1302, MN 1304, source SN 1306, candidate SNs (including, for example, target potential SN 1308 and another potential target SN 1310), core network UPF 1312, and core network AMF 1314. This sample procedure is applicable to, for example, SN / SCG / PSCell additions or SN / SCG / PSCell changes. Figures 13 to 14 The general example process may include: 1. MN 1304 can initiate inter-SN SCG LTM / CLTM by requesting candidate SNs 1308 and 1310 to allocate resources for UE 1302 through the SN addition procedure, for example, similar to Figure 8 Step 1.

[0216] 2 to 7a. These steps are similar to Figure 8 Steps 4 through 8a are part of the LTM / CLTM preparation.

[0217] 8a to 14. These steps are similar to Figure 10 The steps 1 to 9 regarding DL and UL synchronization and SCG LTM cell handover are as follows.

[0218] 15 to 19. These steps are similar to Figure 12 Steps 16 to 20 of the process concerning data forwarding and / or source SN processing after the SCG LTM cell handover (depending on whether the source SN is a candidate SN (e.g., for subsequent LTM handover)).

[0219] In some example implementations, not all steps in the flowchart need to be executed. For example, they can be executed optionally. Figures 11 to 12 and / or Figures 13 to 14 The steps within the dashed box. For example, for an MN-initiated inter-SN LTM used for adding SN / SCG / PSCell, the source SN may not be involved, and... Figures 13 to 14 The steps mentioned above involving the source SN can be ignored / skipped, while the other steps still apply.

[0220] The overall process described above for SN-initiated inter-SN LTMs can also be applied to SCG CLTMs. For SCGCLTMs, Figure 12 Steps 10 to 11 and / or Figure 14Steps 9 and 10 can be ignored / skipped. Instead, the UE can maintain a connection with the source SN after receiving the CLTM configuration and begin evaluating the execution conditions of the CLTM candidate cells. If at least one CLTM candidate cell meets the corresponding execution conditions, the UE can select a candidate cell to perform an LTM cell handover. For example, the UE can detach from the source cell and apply the stored corresponding configuration to the selected candidate cell (e.g., the target cell). If the UE does not have a valid TA for the target cell, the UE can perform a random access procedure to the target cell. If the UE has a valid TA for the target cell, the UE can perform a RACH-free cell handover to the target cell.

[0221] MCG LTM / CLTM and SCG LTM / CLTM coexist In some example implementations, the MN can decide to configure the MCG LTM or the MN-initiated SCG LTM, while the SN can decide to configure the SN-initiated SCG LTM (e.g., including the SN-initiated SCG LTM without the MN and the SN-initiated SCG LTM with the MN).

[0222] In some example scenarios, it may not be possible to configure both MCG LTM and SCG LTM simultaneously. To avoid configuring both MCG LTM and SCG LTM at the same time, it may be necessary to consider some interactions / coordination between MN and SN, including the following example options: Option 1: The MN can send an indicator to the SN to indicate whether the SN can configure the SCG LTM. For example, if the indicator value is set to "Enable" or "True", the SN can configure the SCG LTM. Otherwise, the SN cannot configure the SCG LTM.

[0223] Option 2: The MN can send an indicator to the SN to indicate the maximum number of candidate configurations / cells the SN is allowed to configure for SCG LTM. For example, if the indicator value is set to "0", the SN may not be allowed to configure SCG LTM or SN-initiated SCG LTM. Alternatively, if the indicator does not exist, the SN may be allowed to configure the maximum number (e.g., 8) of candidate configurations / cells the NW is allowed to configure for LTM (e.g., including MCG LTM and / or SCG LTM).

[0224] In some example scenarios, both MCG LTM and SCG LTM can be configured simultaneously. Some interaction / coordination between the MN and SN may need to be considered to ensure that the number of candidate configurations / cells configured by the MN and / or SN does not exceed the maximum number of candidate configurations / cells that the NW is allowed to configure for LTM. Example options may include, but are not limited to: Option 1: The MN can send an indicator to the SN to indicate the maximum number of candidate configurations / cells that the SN is allowed to configure for SCG LTM.

[0225] Option 2: The MN can send an indicator to the SN to indicate the maximum number of candidate configurations / cells the SN is allowed to configure for SCG LTM. If the SN decides to configure more candidate configurations / cells than the indicated value, the SN can send another indicator to the MN to indicate the maximum number of requested / suggested candidate configurations / cells the SN wishes to configure for SCG LTM. The MN can accept or reject the number requested / suggested by the SN. The MN can send a corresponding response to the SN.

[0226] In some example scenarios, both MCG LTM and SCG LTM can be configured simultaneously, but it may not be possible to execute certain types of LTMs concurrently (e.g., MCG LTM and SCG LTM, MN-initiated SCG LTM and SN-initiated SCG LTM). To avoid executing both MCG LTM and SCG LTM simultaneously, some interactions / coordination between the MN and SN may need to be considered. Example options may include, but are not limited to: Option 1: The triggering node (e.g., MN or SN) can coordinate with its counterpart node (e.g., SN or MN) when or before it desires / determines to trigger an LTM. The counterpart node can decide to accept or reject the triggering decision and send a response message to the triggering node. Taking triggering an SCG LTM initiated by SN as an example, the following sample steps can be implemented: ○ Step 1: When or before the SN wants to / determines to trigger the SN-initiated SCG LTM, the SN may send a notification message to the MN to notify that the SN-initiated SCG LTM will be triggered.

[0227] Step 2: The MN can decide whether to accept or reject triggering an SCG LTM initiated by the SN, based on factors such as whether an MCG LTM or an SCG LTM initiated by the MN is currently triggering. The MN can send a corresponding response message to the SN to notify whether the triggering is accepted or rejected. If the MN rejects triggering an SCG LTM initiated by the SN, the response message can include a reason value to indicate the reason for rejection, such as whether an MCG LTM or an SCG LTM initiated by the MN is currently triggering or has already been triggered.

[0228] Step 3: After receiving a response message from the SN (which indicates that the MN accepts the SCG LTM initiated by the SN), the SN can then send a cell handover command to the UE.

[0229] The above options can be applied to triggering an MCG LTM or an SCG LTM initiated by an MN. For example, the MN can coordinate with the SN when or before the MN wants / determines to trigger an MN-initiated LTM.

[0230] Option 2: When or after the triggering node (e.g., MN or SN) sends a cell handover command to the UE to trigger LTM execution, the triggering node may notify its peer node. The peer node may not be allowed to trigger LTM until the ongoing LTM is completed (e.g., before receiving a notification message from the triggering node indicating LTM completion). Taking triggering an LTM initiated by MN as an example, the following sample steps can be implemented: ○Step 1: When or after the MN sends a cell handover command to the UE, the MN may send a notification message to the SN to notify that the MCG LTM or the SCG LTM initiated by the MN has been triggered.

[0231] Step 2: After receiving a notification message from the MN, the SN may not be allowed to trigger the SCG LTM initiated by the SN.

[0232] Step 3: When LTM is completed (e.g., upon receiving an RRC reconfiguration completion message from the UE), the MN can notify the SN, for example, by sending a notification message to the SN to indicate that LTM execution is complete. Then, if necessary, the SN can be allowed to trigger an SN-initiated SCG LTM based on, for example, an L1 measurement report.

[0233] The above options can be applied to triggering an SCG LTM initiated by the SN. For example, when an SCG LTM initiated by the SN is triggered, the SN notifies the MN.

[0234] In some example implementations, the above indicator / information can be transferred between MN and SN via one of the following example options: Option 1: Include the indicator / information directly as, for example, an information element in the Xn / X2 message (e.g., SN add / modify request or SN add / modify request confirmation message).

[0235] Option 2: Include the indicator / information in the RRC message (e.g., CG-ConfigInfo or CG-Config message). This RRC message can be included as an information element in an Xn / X2 message (e.g., SN Add / Modify Request or SN Add / Modify Request Confirmation Message).

[0236] In some example implementations, the above description / method applies to CLTM, for example, MCG CLTM and SCG CLTM coexist. For example, the term "LTM" above may be referred to as "CLTM" or "LTM / CLTM (e.g., including LTM and / or CLTM)".

[0237] Conditional mobility - Execution condition processing To support subsequent conditional mobility (e.g., subsequent CPAC, subsequent CHO, subsequent MCG / SCG CLTM), the execution conditions may need to be updated with cell handover / change. The conditional mobility configuration above can include subsequent condition configurations for each candidate cell. The subsequent condition configurations for a candidate cell will be used when the UE hands over to that candidate cell, for example, to evaluate subsequent execution conditions.

[0238] In some example implementations, subsequent conditional mobility configurations (e.g., ConditionalReconfiguration) may include a list of candidate configurations (e.g., CondReconfigToAddMod List). For each candidate configuration (e.g., CondReconfigToAddMod), it may include at least one of the following pieces of information about the candidate cell: • Candidate configuration ID, for example, condReconfigId; • (One or more) execution conditions, such as condExecutionCond, condExecutionCondSCG; • Candidate cell configuration, for example, condRRCReconfig; • Subsequent condition configuration, such as SubsequentCondReconfig, can include execution conditions that need to be met to trigger the execution of subsequent condition mobility.

[0239] The above-mentioned subsequent condition configuration may include at least one of the following: • A list of subsequent candidate cells (e.g., called condReconfigId). • The associated subsequent execution conditions for each subsequent candidate cell (e.g., condExecutionCond, condExecutionCondSCG), or • List of candidate cells to be released / deleted.

[0240] After receiving subsequent conditional mobility configuration from the NW, the UE should store it in a UE variable (e.g., VarConditionalReconfig).

[0241] After completing a subsequent conditional mobility execution (e.g., successfully completing a random access procedure to a target candidate cell, or successfully completing an LTM cell handover), the UE may need to replace the previous / existing / current execution conditions stored in the UE variables with subsequent execution conditions associated with the target candidate cell (e.g., execution conditions that need to be evaluated and / or satisfied to trigger subsequent conditional mobility execution). Subsequent execution conditions may include candidate cells and associated execution conditions that are different from the current / existing execution conditions, so the UE can replace, add, and / or delete / release the current / existing execution conditions with subsequent execution conditions.

[0242] In some example implementations, when the UE completes subsequent conditional mobility execution from the source cell to the target cell, if the subsequent conditional configuration associated with the target cell includes a list of candidate cells to be released / deleted, the UE may perform at least one of the following operations: • For each indicated candidate cell, remove / release the execution conditions for that candidate cell from the UE variables; or • For each indicated candidate cell, delete / release all information / entries associated with that candidate cell (e.g., candidate cell configuration, execution conditions).

[0243] In some example implementations, when the UE completes subsequent conditional mobility execution from the source cell to the target cell, it may perform at least one of the following operations: • For a candidate cell that is evaluated when the UE is in the source cell and will be evaluated when the UE is in the target cell, for example, if the previous / existing / current execution conditions of the candidate cell are stored in the UE variables and the subsequent execution conditions of the candidate cell exist in the subsequent condition configuration associated with the target cell: the UE replaces the previous / existing / current execution conditions of the candidate cell stored in the UE variables with the subsequent execution conditions of the candidate cell.

[0244] • For candidate cells that are evaluated when the UE is in the source cell but not when the UE is in the target cell, for example, where the previous / existing / current execution conditions of the candidate cell are stored in the UE variables but the subsequent execution conditions of the candidate cell do not exist in the subsequent condition configuration associated with the target cell: the UE should delete the previous / existing / current execution conditions of the candidate cell from the UE variables.

[0245] • For candidate cells that are not evaluated when the UE is in the source cell but will be evaluated when the UE is in the target cell, for example, where the previous / existing / current execution conditions of the candidate cell are not stored in the UE variables, but the subsequent execution conditions of the candidate cell exist in the subsequent condition configuration associated with the target cell: the UE should add the subsequent execution conditions of the candidate cell to the UE variables.

[0246] exist Figure 15 An example is shown in the image.

[0247] In one example, when the UE connects to the source cell (e.g., Cell_0), the NW can pre-configure three candidate cells (e.g., Cell_1, Cell_2, Cell_3) for subsequent conditional mobility. The subsequent conditional mobility configuration includes the execution conditions for each candidate cell and the subsequent execution conditions associated with each candidate cell (e.g., those to be used when a candidate cell becomes the current serving cell). The UE should store the received subsequent conditional mobility configuration in a UE variable.

[0248] • T1: When the UE is in Cell_0, the UE evaluates the execution conditions of all three candidate cells (e.g., condition_01, condition_02, and condition_03).

[0249] • T2: When the UE switches from Cell_0 to Cell_1, the UE needs to replace the previous / existing / current execution condition (i.e., the one used when the UE was in Cell_0) with the subsequent execution condition of Cell_1. Accordingly, the UE needs to: 1) Remove the previous / existing / current execution conditions of Cell_1 from the UE variables; 2) Replace the previous / existing / current execution conditions in the UE variables with the subsequent execution conditions of Cell_2; 3) Remove the previous / existing / current execution conditions of Cell_3 from the UE variables; • T3: When the UE switches from Cell_1 to Cell_2, the UE needs to replace the previous / existing / current execution condition (i.e., the one used when the UE was in Cell_1) with the subsequent execution condition associated with Cell_2. Accordingly, the UE needs to: 1) Add the subsequent execution condition for Cell_1 to the UE variable; 2) Remove the previous / existing / current execution conditions of Cell_2 from the UE variables; 3) Add the subsequent execution condition for Cell_3 to the UE variables; In one example, for instance, for a subsequent CPAC, the sample signaling structure used for subsequent conditional mobility configuration is shown below: –ConditionalReconfiguration IE ConditionalReconfiguration is used to add, modify, and release conditional reconfiguration settings.

[0250] ConditionalReconfiguration information element

[0251] –CondReconfigToAddModList The IE CondReconfigToAddModList contains a list of conditional reconfigurations for adding or modifying, including condReconfigId for each entry and associated fields.

[0252] CondReconfigToAddModList Information Element

[0253] In one example, for instance, for subsequent CPAC, an example procedure (based on the example signaling structure above) for processing the execution conditions of subsequent conditional mobility is as follows:

[0254] The above description and accompanying drawings provide specific example embodiments and implementations. However, the described subject matter can be implemented in a variety of different forms, and therefore, the covered or claimed subject matter is intended to be construed as not being limited to any of the example embodiments set forth herein. A reasonably broad scope is intended for the claimed or covered subject matter. In particular, for example, the subject matter can be implemented as a method, apparatus, component, system, or non-transitory computer-readable medium for storing computer code. Thus, embodiments can take the form of hardware, software, firmware, storage media, or any combination thereof. For example, the above-described method embodiments can be implemented by a component, apparatus, or system including a memory and a processor by executing computer code stored in the memory.

[0255] Throughout the specification and claims, terms may have nuanced meanings implied or implied in the context that go beyond their expressly stated meanings. Similarly, as used herein, the phrase "in one embodiment / implementation" does not necessarily refer to the same embodiment, and as used herein, the phrase "in another embodiment / implementation" does not necessarily refer to a different embodiment. For example, the claimed subject matter is intended to include all or part of the combinations of exemplary embodiments.

[0256] Generally, terms can be understood, at least in part, from their contextual usage. For example, as used herein, terms such as “and,” “or,” or “and / or” can include a variety of meanings that can depend, at least in part, on the context in which such terms are used. Typically, “or,” when used with an associative list, such as A, B, or C, is intended to mean A, B, and C (in an inclusive sense) and A, B, or C (in an exclusive sense). Furthermore, as used herein, the term “one or more” depends, at least in part, on the context and can be used to describe any feature, structure, or characteristic in a singular sense, or a combination of features, structures, or characteristics in a plural sense. Similarly, terms such as “a,” “an,” or “the” can be understood to convey either a singular or a plural usage, at least in part, on the context. Moreover, again, at least in part, on the context, the term “based on” can be understood to not necessarily convey a set of exclusive factors and may instead allow for additional factors that are not necessarily explicitly described.

[0257] References to features, advantages, or similar language throughout this specification do not imply that all features and advantages achievable through this solution should be included or are included in any single implementation thereof. Rather, references to these features and advantages are to be understood as meaning that a particular feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of this solution. Therefore, discussions of features and advantages, as well as similar language, throughout this specification may, but do not necessarily, refer to the same embodiments.

[0258] Furthermore, the features, advantages, and characteristics described herein can be combined in any suitable manner in one or more embodiments. Those skilled in the art, upon reading this description, will recognize that this solution can be practiced without one or more specific features or advantages of a particular embodiment. Additional features and advantages may be recognized in other examples, in some embodiments that may not be present in all embodiments of this solution.

Claims

1. A method performed by a master node (MN) of a wireless network for serving wireless terminals via a source primary-secondary cell (PSCell) in a secondary cell group (SCG), together with a source secondary node (SN), the method comprising: Initiate a Layer 1 / Layer 2 Mobility Measure (LTM) preparation process to obtain LTM configuration; The LTM configuration is transmitted to the wireless terminal; Based on the L1 measurement set, determine to initiate an SCG LTM cell handover so that the wireless terminal can switch from the source PSCell to the target PSCell in the target SN; Transmit an LTM cell handover command to the wireless terminal to trigger the SCG LTM cell handover; as well as When the wireless terminal performs the SCG LTM cell handover from the source PSCell to the target PSCell, it receives a Radio Resource Control (RRC) completion message from the wireless terminal.

2. The method according to claim 1, wherein, The LTM preparation process includes: transmitting an SN Add Request message to each of one or more candidate SNs, wherein the SN Add Request message to each of the one or more candidate SNs includes at least one of the following: Indication used to indicate that LTM has been requested; The identifier of the one or more candidate SNs; The MN recommends one or more candidate cells for the candidate SN; The MN recommends one or more candidate cells for each of the other candidate SNs; The maximum number of candidate cells that the candidate SN can prepare for LTM; The list of SN keys and associated sk-counter values ​​for the candidate SN; The candidate SN can prepare the LTM candidate configuration ID or ID range of one or more candidate cells; Mapping between LTM candidate configuration IDs and the one or more candidate cells; Instructions for requesting the SCG reference configuration; SCG reference cell configuration; Instructions for configuring the L1 reference signal (RS); Instructions for early TA requests to obtain resource configuration; or Instructions for requesting TCI status configuration.

3. The method according to claim 2, wherein, The LTM preparation process further includes: receiving an SN addition request confirmation message from one or more candidate SNs, wherein the SN addition request confirmation message from one or more candidate SNs includes at least one of the following: One or more prepared candidate SN DU IDs; One or more prepared candidate cell IDs; The SCG reference configuration in response to the request indicated for the SCG reference configuration; Candidate SCG configuration for each of the one or more prepared candidate cells; An indicator used to indicate whether the candidate SCG configuration of the corresponding candidate cell is a complete configuration relative to the SCG reference configuration; L1 RS configuration of the one or more prepared candidate cells; Early UL synchronization configuration of the one or more prepared candidate cells; or The TCI status configuration of the one or more prepared candidate cells.

4. The method according to claim 3, wherein, The LTM preparation process further includes: the MN sending an SN modification request message to the source SN or one or more candidate SNs to notify the candidate cell information prepared by the one or more candidate SNs.

5. The method according to claim 4, wherein, The SN modification request message includes at least one of the following: The identifier of the one or more candidate SNs; One or more candidate SN DU IDs; One or more prepared candidate cell IDs; The LTM candidate configuration ID of the prepared candidate cell; The L1 RS configuration of the prepared candidate cells; Early UL synchronization configuration of the prepared candidate cells; The TCI status configuration of the prepared candidate cells; SCG Reference Configuration; or CSI resource configuration for L1 measurement of the prepared candidate cells.

6. The method according to claim 4, further comprising: The MN receives an SN modification request confirmation message from the source SN or one or more candidate SNs in response to the SN modification request message.

7. The method according to claim 6, wherein, The SN modification request confirmation message includes CSI resource configuration or updated SCG configuration for L1 measurement of the prepared candidate cell.

8. The method according to claim 1, wherein, The LTM configuration includes one or more LTM candidate configurations.

9. The method according to claim 8, wherein, The SCG LTM cell handover is performed based on the LTM candidate configuration of the target PSCell.

10. The method according to claim 8, wherein, Each of the one or more candidate LTM configurations includes an indicator that indicates whether the corresponding LTM candidate is for SCG LTM cell handover or MCGLTM cell handover.

11. The method according to claim 1, further comprising: Based on L1 measurements of one or more candidate cells of one or more candidate SNs, the target PSCell for the SCG LTM cell handover is determined, and information about the target PSCell is included in the LTM cell handover command.

12. The method according to claim 11, wherein, Determining the target PSCell for the SCG LTM cell handover includes one of the following: The target PSCell for the SCG LTM cell handover is determined within the DU of the MN based on the L1 measurement; Perform coordination between the DU of the MN and the CU of the MN to determine the target PSCell for the handover of the SCG LTM cell; or Coordination is performed between the MN and the target SN to determine the target PSCell for the SCG LTM cell handover.

13. The method according to claim 1, wherein, The LTM cell handover command includes an LTM cell handover type indicator, which indicates whether the LTM cell handover command is for SCG LTM cell handover or MCG LTM cell handover.

14. The method according to claim 1, wherein, The LTM cell handover command includes a Media Access Control (MAC) control element (MAC CE).

15. The method according to claim 13, wherein, When the LTM cell handover type indicator indicates that the LTM cell handover command is for an SCG LTM cell handover, the SCG LTM cell handover also causes the radio terminal to perform at least one of the following: Indicate to the upper or lower layer of the MAC layer that the LTM cell handover is for SCG LTM cell handover; or The SCG MAC entity of the wireless terminal performs LTM-related operations for the handover of the SCG LTM cell.

16. The method according to claim 15, wherein, The LTM-related operations include at least one of the following: MAC reset, TA processing, selection of uplink authorization configuration, or LTM handover without RACH (no random access channel).

17. The method according to claim 1, wherein, Initiating the SCG LTM cell handover also includes: Send a cell handover notification message to notify the target SN of information associated with the target PSCell, wherein the information associated with the target PSCell includes at least one of the following: the ID of the target PSCell or the TCI status ID of the target PSCell.

18. The method of claim 1, further comprising at least one of the following: Transmit the candidate configuration ID range of the candidate cells proposed for LTM to the candidate SN; or Receive a mapping between candidate cells and candidate configuration IDs prepared by the candidate SN, the mapping being determined by the candidate SN based on the range of candidate configuration IDs.

19. The method according to claim 1, further comprising: After receiving the RRC completion message from the wireless terminal, the system initiates a SN modification or release procedure to the source SN to notify the source SN to either stop providing user data to the wireless terminal or switch to a ready state.

20. A method performed by a wireless terminal, wherein, The wireless terminal is served by a source secondary node (SN) of a wireless network, which serves the wireless terminal through a source primary secondary cell (PSCell) and a primary node (MN) in a secondary cell group (SCG). The method includes: Receive Layer 1 / Layer 2 Triggered Mobility (LTM) configuration from the MN; Receive LTM cell handover command from the MN; and According to the LTM cell handover command and the LTM configuration, perform an SCG LTM cell handover from the source PSCell to the target PSCell of the target SN.

21. The method of claim 20, further comprising: Before receiving the LTM cell handover command, perform UL synchronization with the candidate SN for use in the SCG LTM cell handover.

22. The method according to claim 21, wherein, The UL synchronization includes receiving random access indication signaling from the source SN to trigger the UL synchronization through an early random access procedure between the wireless terminal and the candidate SN.

23. The method according to claim 20, wherein, The LTM cell handover command includes information associated with the target PSCell, which is determined in the following way: Determined within the DU of the MN; Determined by the coordination between the DU and CU of the MN; or It is determined by the coordination between the MN and the target SN.

24. The method of claim 20, wherein, The LTM cell handover command includes an LTM cell handover type indicator, which indicates whether the LTM cell handover command is for SCG LTM cell handover or MCG LTM cell handover.

25. The method according to claim 20, wherein, The LTM cell handover command includes a Media Access Control (MAC) control element (MAC CE).

26. The method of claim 24, wherein, When the LTM cell handover type indicator indicates that the LTM cell handover command is for an SCG LTM cell handover, the SCG LTM cell handover further includes performing at least one of the following: Indicate to the upper or lower layer of the MAC layer that the LTM cell handover command is for SCG LTM cell handover; or The SCG MAC entity of the wireless terminal performs LTM-related operations for the handover of the SCG LTM cell.

27. The method according to claim 26, wherein, The LTM-related operations include at least one of the following: MAC reset, TA processing, selection of uplink authorization configuration, or LTM handover without RACH (no random access channel).

28. The MN or wireless terminal according to any one of claims 1 to 27, comprising a processor and a memory, wherein, The processor is configured to read code from the memory to implement the method according to any one of claims 1 to 27.

29. A computer program product comprising a computer-readable program medium on which code is stored, the code, when executed by a processor of an MN or wireless terminal according to any one of claims 1 to 27, causes the processor to implement the method according to any one of claims 1 to 27.

Images