User-plane methods in layer- 1 / layer-2 triggered mobility

Abstract

This disclosure is directed generally to wireless communications technologies and more specifically to user-plane procedures for downlink and uplink synchronization, earlier data transfer, and execution of Layer- 1 / Layer-2 Triggered Mobility (LTM) and / or conditional LTM (CLTM). Example implementations are provided under coexistence of cell switches by network triggered LTM and user equipment (UE) determined CLTM with respect to early downlink and uplink synchronization between the UE and candidate / target cell(s) and early data / status forwarding from a source cell to a candidate / target cell in order to improve cell switching latency and reduce cell switching overhead. These implementations further take into consideration that some candidate / target cells may support multiple Transmit Receive Points (mTRPs) and multiple Time Advances (mTAs) for uplink timing.

Description

USER-PLANE METHODS IN LAYER-1 / LAYER-2 TRIGGERED MOBILITYTECHNICAL FIELD

[0001] This disclosure is directed generally to wireless communications technologies and more specifically to user-plane procedures for downlink and uplink synchronization, earlier data transfer, and execution of Layer-1 / Layer-2 Triggered Mobility (LTM) and / or conditional LTM (CLTM) .BACKGROUND

[0002] In a wireless network, a wireless terminal device in communication with a serving cell may need to switch cells during mobility. It is desirable for such cell switches to be performed with reduced mobility latency, data interruption time, communication overhead and / or energy consumption in various network architectures and topologies.SUMMARY

[0003] This disclosure is directed generally to wireless communications technologies and more specifically to user-plane procedures for downlink and uplink synchronization, earlier data transfer, and execution of Layer-1 / Layer-2 Triggered Mobility (LTM) and / or conditional LTM (CLTM) . Example implementations are provided under coexistence of cell switches by network triggered LTM and user equipment (UE) determined CLTM with respect to early downlink and uplink synchronization between the UE and candidate / target cell (s) and early data / status forwarding from a source cell to a candidate / target cell in order to improve cell switching latency and reduce cell switching overhead. These implementations further take into consideration that some candidate / target cells may support multiple Transmit Receive Points (mTRPs) and multiple Time Advances (mTAs) for uplink timing.

[0004] In some example implementations, a method performed by a user equipment (UE) in a wireless communication system is disclosed. The method may include receiving, from a serving cell for the UE, a Layer-1 / Layer-2 Triggered Mobility (LTM) configuration for one or more candidate cells for an LTM cell switch or a conditional LTM (CLTM) cell switch, the one or more candidate cells comprising at least one inter-CU (Central Unit) candidate cell from the  serving cell; performing an early downlink (DL) synchronization and an early uplink (UL) synchronization with the one or more candidate cells; and executing the LTM cell switch or the CLTM cell switch from the serving cell to a target cell among the one or more candidate cells according to the LTM configuration, the early DL synchronization and the early UL synchronization.

[0005] In the example implementations above, the at least one of the one or more candidate cells comprises multiple transmit-receive points (mTRPs) associated with two or more distinct time advances (TAs) for uplink communications with the UE.

[0006] In any one of the example implementations above, the early DL synchronization comprises: receiving a transmission control indicator (TCI) state activation / deactivation media access control (MAC) control element (MAC CE) from the serving cell, the TCI state activation / deactivation MAC CE indicating a set of TCI states for activation in the at least one of the one or more candidate cells and indicating a corresponding control resource set pool (CORESET POOL) identifier (CORESET POOL ID) .

[0007] In any one of the example implementations above, the early DL synchronization comprises: receiving a TCI state activation / deactivation MAC CE from the at least one of the one or more candidate cells, the TCI state activation / deactivation MAC CE indicating a plurality of codepoints and corresponding sets of joint mode or separate mode TCI states for activation in the at least one of the one or more candidate cells.

[0008] In any one of the example implementations above, UE-based TA measurements for the early UL synchronization are disallowed with respect to the at least one inter-CU candidate cell.

[0009] In any one of the example implementations above, UE-based TA measurements for the early UL synchronization are allowed for the at least one of the one or more candidate cells associated with the two or more distinct TAs, and a correspondence relationship between reference signals to be measured and the two or more distinct TAs are predefined, or specified in a configurable mapping relationship from network side, or determined by the UE.

[0010] In any one of the example implementations above, the UE is configured to perform  the CLTM cell switch, and wherein the method further comprises performing a preparation and reporting procedure for a transmission status with respect to the serving cell upon performing the CLTM cell switch.

[0011] In any one of the example implementations above, the transmission status comprises identifying a first unreceived un-acknowledgement mode (UM) data unit by the UE from the serving cell.

[0012] In any one of the example implementations above, the preparation procedure for the transmission status may include storing a counter or sequence number of the first unreceived UM data unit upon a successful termination of the CLTM cell switch; and generating a protocol data unit including the stored counter or sequence number.

[0013] In any one of the example implementations above, the reporting procedure for the transmission status comprises sending the protocol data unit to the target cell for the target cell to determine which data units of earlier transfer data from the serving cell to the target cell have already been received by the UE prior to the CLTM cell switch and can be discarded from transmission at the target cell.

[0014] In any one of the example implementations above, the UE is configured to perform both the LTM cell switch and the CLTM cell switch, and wherein the early DL synchronization may include receiving, from the serving cell, TCI state activation / deactivation MAC CEs indicating sets of TCI states to activate for the one or more candidate cells; and selecting only from the sets of TCI states when determining and performing the CLTM cell switch.

[0015] In any one of the example implementations above, the UE is configured to perform both the LTM cell switch and the CLTM cell switch, and wherein the early DL synchronization may include performing L1 measurements on the one or more candidate cells; determining TCI states to be activated for the one or more candidate cells according to the L1 measurements; and informing the one or more candidate cells of the TCI states to be activated using UL signaling.

[0016] In any one of the example implementations above, the UL signaling comprises one or more UL MAC CEs.

[0017] In any one of the example implementations above, each of the one or more UL MAC  CEs comprises at least one of: indication of at least one UL / DL / Joint TCI State to be activated; or code point of a Downlink Control Information (DCI) for a present UL / DL / Joint TCI state.

[0018] In any one of the example implementations above, the UE is configured to perform the CLTM cell switch, and wherein the early UL synchronization comprises triggering a Physical Downlink Control Channel (PDCCH) ordered early RACH procedure, the PDCCH ordered early RACH procedure including receiving random access responses (RARs) from the serving cell in order to obtain TAs associated with the one or more candidate cells.

[0019] In any one of the example implementations above, the UE is configured to perform the CLTM cell switch, and wherein the early UL synchronization may include triggering a Physical Downlink Control Channel (PDCCH) ordered early RACH procedure, the PDCCH ordered early RACH procedure being without RARs; and receiving DL MAC CEs from the serving cell containing TAs associated with the one or more candidate cells.

[0020] In any one of the example implementations above, the UE is configured to perform the CLTM cell switch, and wherein the early UL synchronization may include initiating an early RACH procedure with RAR presence; and receiving RARs from the serving cell or the one or more candidate cells to extract TAs associated with the one or more candidate cells.

[0021] In some other implementations, corresponding methods performed by the serving cell above are disclosed and corresponding methods performed by the candidate or target cell above are also disclosed.

[0022] In some other implementations, a wireless communications apparatus is disclosed. The wireless communication apparatus may include at least one processor and a memory, wherein the at least one processor is configured to read code from the memory and implement any one of the methods above.

[0023] In yet some other implementations, a non-transitory computer readable medium is disclosed. The non-transitory computer readable medium may include computer instructions, when executed by at least one processor of a wireless communication device, may cause the wireless communication device to implement any one of the methods above.BRIEF DESCRIPTION OF THE DRAWINGS

[0024] FIG. 1 illustrates an example wireless communication network including a wireless access network, a core network, and data networks.

[0025] FIG. 2 illustrates an example wireless access network including a plurality of mobile stations / terminals or User Equipments (UEs) and a wireless access network node in communication with one another via an over-the-air radio communication interface.

[0026] FIG. 3 shows an example radio access network (RAN) architecture.

[0027] FIG. 4 shows an example communication protocol stack in a wireless access network node or wireless terminal device including various network layers.

[0028] FIG. 5 illustrates an example LTM procedure.

[0029] FIG. 6 illustrates an example conditional LTM procedure.

[0030] FIG. 7 illustrates an example modified Transmission Configuration Indicator (TCI) state activation / deactivation Media Access Control (MAC) Control Element (MAC CE) .

[0031] FIG. 8 illustrates another example modified TCI state activation / deactivation MAC CE.

[0032] FIG. 9 illustrates an example DU-CU (Distributed Unit-Central Unit) communication of activated TCI states.

[0033] FIG. 10 illustrates an example CU-DU communication of activated TCI states to a target DU.

[0034] FIG. 11 illustrates an example CU-CU (Distributed Unit-Central Unit) communication of activated TCI states from a source CU to a target CU.

[0035] FIG. 12 illustrates an example uplink MAC CE for indicating activated TCI states.

[0036] FIG. 13 illustrates an example data and logic flow for early RACH with Random Access Response (RAR) .

[0037] FIG. 14 illustrates an example data and logic flow for early RACH without RAR but with downlink MAC CE for providing time advance (TA) information.

[0038] FIG. 15 illustrates an example Time Advance Control (TAC) MAC CE.

[0039] FIG. 16 illustrates another example TAC MAC CE.

[0040] FIG. 17 illustrates yet another example TAC MAC CE.

[0041] FIG. 18 an example data and logic flow for early RACH triggered by MAC entity.

[0042] FIG. 19 an example data and logic flow for a CLTM execution procedure.DETAILED DESCRIPTION

[0043] The present disclosure will now be described in detail hereinafter with reference to the accompanied drawings, which form a part of the present disclosure, and which show, by way of illustration, specific examples of embodiments. The present disclosure may, however, be embodied 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 embodiments to be set forth below.

[0044] Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment” or “in some embodiments” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment” or “in other embodiments” as used herein does not necessarily refer to a different embodiment. The phrase “in one implementation” or “in some implementations” as used herein does not necessarily refer to the same implementation and the phrase “in another implementation” or “in other implementations” as used herein does not necessarily refer to a different implementation. It is intended, for example, that claimed subject matter includes combinations of exemplary embodiments or implementations in whole or in part.

[0045] In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and” , “or” , or “and / or, ” as used herein may include a variety of meanings that may depend at least in part upon the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C,  here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” or “at least one” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a” , “an” , or “the” , again, may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” or “determined by” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

[0046] Wireless Network Overview

[0047] An example wireless communication network, shown as 100 in FIG. 1, may include wireless terminal devices or user equipment (UE) 110, 111, and 112, a carrier network 102, various service applications 140, and other data networks 150. The wireless terminal devices or UEs, may be alternatively referred to as wireless terminals. The carrier network 102, for example, may include access network nodes 120 and 121, and a core network 130. The carrier network 110 may be configured to transmit voice, data, and other information (collectively referred to as data traffic) among UEs 110, 111, and 112, between the UEs and the service applications 140, or between the UEs and the other data networks 150. The 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 UEs on one side of a communication session and the core network 130 on the other. The term “access network” may be used more broadly to refer a combination of the wireless terminal devices 110, 111, and 112 and the access network nodes 120 and 121. A wireless access network may be alternatively referred to as 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. The service applications 140 may be hosted by various application servers deployed outside of but connected to the core network 130. Likewise, the other data networks 150 may also be connected to the core network 130.

[0048] In the example wireless communication network of 100 of FIG. 1, the UEs may  communicate with one another via the wireless access network. For example, UE 110 and 112 may be connected to and communicate via the same access network node 120. The UEs may communicate with one another via both the access networks and the core network. For example, UE 110 may be connected to the access network node 120 whereas UE 111 may be connected to the access network node 121, and as such, the UE 110 and UE 111 may communicate to one another via the access network nodes 120 and 121, and the core network 130. The UEs may further communicate with the service applications 140 and the data networks 150 via the core network 130. Further, the UEs may communicate to one another directly via side link communications, as shown by 113.

[0049] FIG. 2 further shows an example system diagram of the wireless access network 120 including a WANN 202 serving UEs 110 and 112 via the over-the-air interface 204. The wireless transmission resources for the over-the-air interface 204 include a combination of frequency, time, and / or spatial resource. Each of the UEs 110 and 112 may be a mobile or fixed terminal device installed with mobile access units such as SIM / USIM modules for accessing the wireless communication network 100. The UEs 110 and 112 may each be implemented as a terminal device including but not limited to a mobile phone, a smartphone, a tablet, a laptop computer, a vehicle on-board communication equipment, a roadside communication equipment, a sensor device, a smart appliance (such as a television, a refrigerator, and an oven) , or other devices that are capable of communicating wirelessly over a network. As shown in FIG. 2, each of the UEs such as UE 112 may include transceiver circuitry 206 coupled to one or more antennas 208 to effectuate wireless communication with the WANN 120 or with another UE such as UE 110. The transceiver circuitry 206 may also be coupled to a processor 210, which may also be coupled to a memory 212 or other storage devices. The memory 212 may be transitory or non-transitory and may store therein computer instructions or code which, when read and executed by the processor 210, cause the processor 210 to implement various ones of the methods described herein.

[0050] Similarly, the WANN 120 may include a wireless base station or other wireless network access point capable of communicating wirelessly via the over-the-air interface 204 with one or more UEs and communicating with the core network 130. For example, the WANN 120 may be implemented, without being limited, in the form of a 2G base station, a 3G  nodeB, an LTE eNB, a 4G LTE base station, a 5G NR base station of a 5G gNB, a 5G central-unit base station, or a 5G distributed-unit base station. Each type of these WANNs may be configured to perform a corresponding set of wireless network functions. The WANN 202 may include transceiver circuitry 214 coupled to one or more antennas 216, which may include an antenna tower 218 in various forms, to effectuate wireless communications with the UEs 110 and 112. The transceiver circuitry 214 may be coupled to one or more processors 220, which may further be coupled to a memory 222 or other storage devices. The memory 222 may be transitory or non-transitory and may store therein instructions or code that, when read and executed by the one or more processors 220, cause the one or more processors 220 to implement various functions of the WANN 120 described herein.

[0051] Data packets in a wireless access network such as the example described in FIG. 2 may be transmitted as protocol data units (PDUs) . The data included therein may be packaged as PDUs at various network layers wrapped with nested and / or hierarchical protocol headers. The PDUs may be communicated between a transmitting device or transmitting end (these two terms are used interchangeably) and a receiving device or receiving end (these two terms are also used interchangeably) once a connection (e.g., a radio link control (RRC) connection) is established between the transmitting and receiving ends. Any of the transmitting device or receiving device may be either a wireless terminal device such as device 110 and 120 of FIG. 2 or a wireless access network node such as node 202 of FIG. 2. Each device may both be a transmitting device and receiving device for bi-directional communications.

[0052] The core network 130 of FIG. 1 may include various network nodes geographically distributed and interconnected to provide network coverage of a service region 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 as software entities. These network nodes may each be configured with one or more types of network functions which collectively provide the provisioning and routing functionalities of the core network 130.

[0053] Returning to wireless radio access network (RAN) , FIG. 3 illustrates an example RAN 340 in communication with a core network 310 and wireless terminals UE1 to UE7. The  RAN 340 may include one or more various types of wireless base station or WANNs 320 and 321 which may include but are not limited to gNB, eNodeB, NodeB, or other type of base stations. The RAN 340 may be backhauled to the core network 310. The WANNs 320, for example, may further include multiple separate access network nodes in the form of a Central Unit (CU) 322 and one or more Distributed Unit (DU) 324 and 326. The CU 322 is connected with DU1 324 and DU2 326 via various interfaces, for example, an F1 interface. The F1 interface, for example, 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, the CU may be a gNB Central Unit (gNB-CU) , and the DU may be a gNB Distributed Unit (gNB-DU) . While the various implementations described below are provided in the context of a 5G cellular wireless network, the underlying principles described herein are applicable to other types of radio access networks including but not limited to other generations of cellular network, as well as Wi-Fi, Bluetooth, ZigBee, and WiMax networks.

[0054] The UEs may be connected to the network via the WANNs 320 over an air interface. The UEs may be served by at least one cell. Each cell is associated with a coverage area. These cells may be alternatively referred to as serving cells. The coverage areas between cells may partially overlap. Each UE may be actively communicating with at least one cell while may be potentially connected or connectable to more than one cell. In some example implementations, a DU of FIG. 3 may support one or multiple cells and one cell is supported by only one DU. In the example of FIG. 3, UE1, UE2, and UE3 may be served by cell1 330 of the DU1, whereas UE4 and UE5 may be served by cell2 332 of the DU1, and UE6 and UE7 may be served by cell3 associated with DU2. In some implementations, a UE may be served simultaneously by two or more cells. Each of the UE may be mobile and the signal strength and quality from the various cells at the UE may depend on the UE location and mobility.

[0055] FIG. 4 further illustrates a simplified view of the various network layers involved in transmitting user-plane PDUs from a transmitting device 402 to a receiving device 404 in the example wireless access network of FIGs. 1-3. FIG. 4 is not intended to be inclusive of all essential device components or network layers for handling the transmission of the PDUs. FIG. 4 illustrates that the data packaged by upper network layers 420 at the transmitting device 402  may be transmitted to corresponding upper layer 430 (such as radio resource control or RRC layer) at the receiving device 304 via Packet Data Convergence Protocol layer (PDCP layer, not shown in FIG. 4) and radio link control (RLC) layer 422 and of the transmitting device, the physical (PHY) layers of the transmitting and receiving devices and the radio interface, as shown as 406, and the media access control (MAC) layer 434 and RLC layer 432 of the receiving device. Various network entities in each of these layers may be configured to handle the transmission and retransmission of the PDUs.

[0056] In FIG. 4, the upper layers 420 may be referred as layer-3 or L3, whereas the intermediate layers such as the RLC layer and / or the MAC layer and / or the PDCP layer (not shown in FIG. 4) may 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-associated layers. In some instances, the term “low layer” may be used to refer to a collection of L1 and L2, whereas the term “high layer” may be used to refer to layer-3. In some situations, the term “lower layer” may be used to refer to a layer among L1, L2, and L3 that are lower than a current reference layer. Control signaling may be initiated and triggered at each of L1 through L3 and within the various network layers therein. These signaling messages may be encapsulated and cascaded into lower layer packages and transmitted via allocated control or data over-the-air radio resources and interfaces. The term “layer” generally includes various corresponding entities thereof. For example, a MAC layer encompasses corresponding MAC entities that may be created. The layer-1 (L1) , for example, encompasses PHY entities. The layer-2 (L2) , for another example encompasses MAC layers / entities, RLC layers / entities, service data adaptation protocol (SDAP) layers and / or PDCP layers / entities.

[0057] In some example CU / DU splitting implementations shown in FIG. 3, the CU 322 may be defined as a logical node hosting higher layer RRC, SDAP and PDCP protocols of the example gNB or RRC and PDCP protocols or protocol entities of the example en-gNB that controls the operation of the one or more example DUs 324 and 326. The example DUs 324 and 326 may each be defined as a logical node hosting lower layer RLC, MAC and PHY protocol or protocol entities of the gNB or en-gNB, with its operation partly controlled by CU 322.

[0058] In some example implementations, the cells shown in FIG. 3 may be alternatively referred to as serving cells. The serving cells may be grouped into serving cell groups (CGs) . A serving cell group may be either a Master CG (MCG) or Secondary CG (SCG) . Within each type of cell groups, there may be one primary cell and one or more secondary cells. A primary cell in a MSG, for example, may be referred to as a PCell, whereas a primary cell in a SCG may be referred to as PSCell. Secondary cells in either an MCG or an SCG may be all referred to as SCell. The primary cells including PCell and PSCell may be collectively referred to as spCell (special Cell) . All these cells may be referred to as serving cells or cells. The term “cell” and “serving cell” may be used interchangeably in a general manner unless specifically differentiated. The term “serving cell” may refer to a cell that is serving, will serve, or may serve the UE. In other words, a “serving cell” may not be currently serving the UE. While the various embodiment described below may at times be referred to one of the types of serving cells above, the underlying principles apply to all types of serving cells in both types of serving cell groups.

[0059] L1 / L2 Triggered Mobility in Intra-CU Cell Switch Context

[0060] Mobility of a UE from a source serving cell to a target serving cell may be triggered at various network layers in the wireless network above. Mobility triggered at lower level may general provide fewer reconfigurations and less latency, thereby providing faster cell switches with less network overhead. For example, Layer 1 / Layer 2 Triggered Mobility (LTM) may include a procedure in which a gNB (generally representing a base station) receives L1 measurement report (s) from a UE, and on that basis the gNB changes UE’s serving cell by a cell switch command signaled via, for example, a MAC CE. The cell switch command indicates as a target cell an LTM candidate cell with a cell configuration that the gNB has previously prepared and provided to the UE through RRC signaling. Then the UE switches to the target cell according to the cell switch command. The cell switch command may be conveyed in a MAC CE, which contains necessary information to perform the LTM cell switch.

[0061] LTM may be implemented for cell switches between serving cells within a same gNB or base station (e.g., intra-CU cell switches) . An overall example procedure for such an LTM is shown in FIG. 5, including, for example, an LTM preparation procedure A1, an early  synchronization procedure A2, an LTM cell switching execution procedure A3, and an LTM cell switch completion procedure A4. Subsequent LTM may be performed by repeating the early synchronization A2, LTM cell switch execution A3, and LTM cell switch completion A4 steps without releasing other LTM candidate cell configurations after each LTM cell switch completion. FIG. 5 may be applied to a scenario where the cell switch is intra-CU, and as such only one gNB is involved as explicitly illustrated in FIG. 5 and the LTM cell switch may occur between a source cell and a target cell associated with the same gNB. The example general procedure of FIG. 5 may be applicable to Main-Cell-Group (MCG) LTM cell switching and / or Secondary-Cell-Group SCG LTM cell switching.

[0062] The general LTM procedure of FIG. 5 applies to inter-CU LTM, where the gNB in FIG. 5 may generally be either a source gNB, a candidate gNB or target gNB, as will be described in further detail in the various disclosure below. While the notation “gNB” is used in FIG. 6 and in the various example implementations described below for CLTM and throughout this disclosure, it may be considered as representing any type of base stations. Each of such base stations, may include a CU and one or more DUs, as shown in FIG. 3.

[0063] The example general procedure of FIG. 5 for LTM is described as follows. The numeral headers represent the corresponding steps of FIG. 5.

[0064] LTM Preparation Procedure A1:

[0065] 1. The UE sends a MeasurementReport message to the gNB in the current communication connection with a source cell associated with the gNB. The gNB receives MeasurementReport message and then decides, based on the MeasurementReport message, to initiate LTM preparation to configure future LTM cell switch.

[0066] 2. The gNB transmits an RRCReconfiguration message to the UE including the LTM candidate cell configurations for candidate cells.

[0067] 3. The UE stores the LTM candidate cell configurations and transmits an RRCReconfigurationComplete message to the gNB. Steps 1-3 may be collectively referred to as an LTM preparation procedure.

[0068] Earlier Synchronization Procedure A2:

[0069] 4a. The UE may perform downlink (DL) synchronization with the candidate cell (s)

[0070] before receiving the cell switch command.

[0071] 4b. If configured / indicated by the network, the UE may perform UE-based Time Advance (TA) measurement (s) or PDCCH order triggered early RACH to acquire the TA value (s) of one or multiple candidate cells before receiving the cell switch command. For UE-based Time Advance (TA) measurement (s) , the UE performs TA measurement (s) for the candidate cells after being configured by RRC but the exact timing for the UE to perform the TA measurement (s) is up to UE implementation. For PDCCH order triggered early RACH, this may be done via Contention Free Random Access (CFRA) triggered by a Physical Downlink Control Channel (PDCCH) order from the source cell, following which the UE sends preamble towards the indicated candidate cell. Then the indicated candidate cell calculates the TA value (s) . In order to minimize the data transmission interruption of the source cell in the current communication with the UE due to the CFRA towards the candidate cell (s) , the candidate cell (s) may not transmit and the UE may not receive Random Access Response (RAR) for the purpose of TA value acquisition, and the TA value (s) of the candidate cell (s) may be indicated in the cell switch command to the UE. The UE may not maintain TA timer (s) for the candidate cell (s) , and may rely on network implementation to guarantee TA validity instead. Steps 4a and 4b above may be collectively referred to as an early synchronization procedure.

[0072] LTM Cell Switch Execution Procedure A3:

[0073] 5. The UE performs L1 measurements on the configured candidate cell (s) and transmits L1 measurement reports to the gNB. L1 measurements should be performed as long as the RRC reconfiguration message (received in Step 2) is applied by the UE.

[0074] 6. The gNB may decide to execute cell switch to a target cell (among the candidate cell (s) ) and transmits, e.g., a MAC CE triggering the cell switch by including a  candidate configuration index of the target cell (for identifying the target cell configuration among one or more candidate cells) . The UE may then switch to the target cell and apply the cell configuration indicated by the candidate configuration index.

[0075] 7. The UE performs the random access procedure towards the target cell, if UE does not already have a valid TA of the target cell from, for example, the synchronization procedure above. The random access procedure of Step 7 may be omitted if the UE has already obtained a valid TA of the target cell. Steps 5 through 7 above may be collectively referred to as LTM cell switch execution procedure.

[0076] LTM Cell Switch Completion Procedure A4:

[0077] 8. The UE completes the LTM cell switch procedure by sending RRCReconfigurationComplete message to the target cell. If the UE has performed a random access procedure in Step 7 above, the UE may consider that LTM cell switch execution is successfully completed when the random access procedure is successfully completed. For RACH-less LTM (where Step 7 is omitted) , the UE may instead consider that LTM cell switch execution is successfully completed when the UE determines that the network has successfully received its first UL data.

[0078] The Steps 4-8 above can be performed multiple times for subsequent LTM using the LTM candidate configuration (s) provided in Step 2.

[0079] Conditional Mobility

[0080] In some example implementations, conditional mobility may be implemented in cell switching, where the UE determines to switch from a source serving cell to a target serving cell based on pre-configured condition (s) rather than according to cell switch command from the network. The conditional mobility can include both conditional LTM (CLTM) and conditional layer-3 (L3) mobility. Specifically, in some example implementations, conditional mobility may be applied to LTM, i.e., CLTM. In some other example implementations, conditional mobility at various network layers may include, for example, at least one of Conditional Handover (CHO) , conditional LTM, Conditional PSCell Addition (CPA) , Conditional PSCell  Change (CPC) , subsequent Conditional PScell Addition / Change (CPAC) , and the like. In the disclosure below, some relevant portions, while being described in the context of LTM, may be applicable to any one of the types for conditional mobility.

[0081] The term Conditional LTM (CLTM) , in particular, may be used to refer to an LTM cell switch that is executed by the UE when one or more execution / triggering condition (s) are met. The UE may start evaluating the execution condition (s) upon receiving an CLTM configuration and stops evaluating the execution condition (s) upon / once a cell switch or a PCell / PSCell change is triggered, e.g., according to the CLTM configuration from the NW.

[0082] The CLTM can be generally applicable to MCG cell switch and / or SCG cell switch. The LTM related configuration may be applied to CLTM for the underlying LTM.

[0083] An example overall procedure of CLTM is shown in FIG. 6, applicable to both intra-CU and inter-CU CLTM. The gNB of the overall CLTM procedure of FIG. 6, in the inter-CU LTM situations, would correspondingly include either or both of a source gNB and / or a candidate / target gNB. It may also represent a combination of a source gNB and a target / candidate gNB for inter-CU CLTM purposes. The example overall procedure of CLTM shown in FIG. 6 may include the following example steps (the numerical headers below correspond to the steps in FIG. 6) :

[0084] LTM Preparation Procedure B1:

[0085] 1. The UE sends a MeasurementReport message to the gNB. The gNB decides to configure CLTM and initiates a CLTM preparation.

[0086] 2. The gNB transmits an RRCReconfiguration message to the UE including a CLTM configuration, e.g., including one or more candidate configurations, and execution condition (s) for each candidate.

[0087] 3. The UE stores the candidate configurations and transmits an RRCReconfigurationComplete message to the gNB.

[0088] Earlier Synchronization Procedure B2:

[0089] 4a. The UE may perform DL synchronization with the candidate cell (s) .

[0090] 4b. The UE may perform UL synchronization with the candidate cell (s) , e.g., via UE-based TA measurement or PDCCH triggered early RACH.

[0091] Conditional LTM Cell Switch Execution Procedure B3

[0092] 5. The UE maintains connection with the source gNB after receiving the CLTM configuration, and starts evaluating the execution conditions for the CLTM candidate cell (s) as long as the RRC reconfiguration message (received in Step 2) is applied by the UE. If at least one CLTM candidate cell satisfies the corresponding execution condition (s) , the UE selects a candidate cell to perform the LTM cell switch, e.g., by detaching from the source cell of the source gNB, and applies the stored corresponding candidate configuration for the selected candidate cell (i.e., target cell) . If UE does not already have valid TA of the target cell, the UE performs a random access (RA) procedure towards the target cell. If the UE already has a valid TA of the target cell, the UE performs RACH-less cell switch to the target cell.

[0093] Conditional LTM Cell Switch Completion Procedure B4:

[0094] 6. The UE completes the LTM cell switch procedure by sending RRCReconfigurationComplete message to target cell. If the UE has performed an RA procedure in step 5 above, the UE considers that LTM cell switch execution is successfully completed when the RA procedure is successfully completed. For RACH-less LTM, the UE considers that LTM cell switch execution is successfully completed when the UE determines that the network has successfully received its first UL data.

[0095] The Steps 4-6 of FIG. 6 above can be performed multiple times for subsequent CLTM using the LTM candidate configuration (s) and execution condition (s) provided in Step 2.

[0096] Extended LTM

[0097] In some example implementations, the general procedure and the underlying principles of LTM in FIG. 5 may be extended to conditional LTM of FIG. 6. In addition, the LTM of FIG. 5 and the conditional LTM of FIG. 6 may be further applied or extended to  scenarios beyond intra-CU. For example, such LTM and / or conditional LTM may be applied to inter-CU cell switching in addition to, for example, intra-CU inter-DU cell switching cases and intra-CU intra-DU cell switching cases.

[0098] As examples, such extended LTM or conditional LTM may be supported for at least one of the following scenarios:

[0099] ● LTM in Stand-Alone (SA) or Carrier Aggregation (CA) ;

[0100] ● MCG LTM in dual connect DC (e.g., NR-DC) , e.g., including MCG LTM cell switching with SCG / SN (Secondary Cell Group / Secondary Node) release, MCG LTM cell switching with SCG / SN addition, MCG LTM cell switching without SCG / SN change, or MCG LTM cell switching with SCG / SN change;

[0101] ● SCG LTM in DC (e.g., NR-DC) , e.g., including SCG LTM cell switching with MCG / MN (Master Cell Group / Master Node) change / involvement, or SCG LTM cell switching without MCG / MN change / involvement.

[0102] In the disclosure below, the term SCG LTM may be defined as a PSCell / SCG switch / change procedure that the network (NW) triggers via MAC CE based on L1 measurement. The term SCG LTM may include both intra-SN cases (e.g., the source cell and target cell belong to the same SN CU) and inter-SN cases (e.g., the source cell and target cell belong to different SN CUs) . From the perspective of initiation node of LTM preparation, SCG LTM can be classified as MN initiated SCG LTM or SN initiated SCG LTM. From the perspective for the involvement of MN, the SCG LTM can be classified as intra-SN SCG LTM without MN involvement, intra-SN SCG LTM with MN involvement, and MN / SN initiated inter-SN SCG LTM.

[0103] The general LTM and CLTM implementations of FIGs. 5 and 6 may be applied to all these different scenarios. Again, the gNB of FIGs. 5 and 6, in the inter-CU LTM situations, would correspondingly include both a source gNB and a target gNB (and / or other candidate gNBs) . While the notation “gNB” is used in FIGs. 5 and 6 and in the various example implementations described below, it may be considered as representing any type of base stations. Each of the such base stations, may include a CU and one or more DUs, as shown in FIG. 3.

[0104] While the description below mainly focuses on the inter-SN SCG LTM, the underlying principles and similar methods / procedures may also be applicable to other LTM cases, e.g., intra-SN SCG LTM, and MCG LTM. The disclosure below applies to either or both of MCG LTM and SCG LTM unless specified otherwise. In the disclosure below involving SCG LTM, the term “candidate cell” is used to refer to SCG candidate cell (e.g., candidate PSCell) . The LTM related configuration / procedure can be applicable to the CLTM as well.

[0105] Time Advance (TA) in Multiple Transmit-Receive Point (mTRP) Transmission

[0106] Multiple Transmit-Receive Points (mTRP) transmission technology allows wireless access network nodes and a UEs to use different antenna panels and / or RF chains to perform the transmission-reception (RX-TX) . In other words, the mTRP technology allow the wireless network and / or a UE to transmit / receive the multiple radio / data streams simultaneously.

[0107] For example, a serving cell for a UE may be provided with one or more antenna panels from the network side. Each antenna panel may be configured with multiple beams. A beam may be used as a TRP. As such, mTRP service may be provided by the serving cell to the UE via two or more beams from the same or different antennal panels at the same time. Using mTRP provided by the same serving cell may be referred to as intra-cell mTRP.

[0108] Each of the TRP may be associated with its own uplink TA depending on the signal path of the corresponding beam from the UE to the TRP. Among all configurable TRPs, a subset, e.g., two or more, of the TRPs may be actively used to provide mTRP service to the UE for uplink transmission at the same time. The UE, for example, may be configured with TA Groups (TAG) to manage uplink TAs. Each TAG may be associates with a TA value to apply for uplink transmission. The UE may be configured to simultaneously manage multiple TAGs identified by TAG IDs in order to maintain multiple TAs. In the single TRP (sTRP) situation, a cell may be associated with one TAG while each TAG may be associated with multiple cells having similar TAs. For the UE to apply a correct TA value for uplink transmission, the UE may obtain a TAG ID from a scheduling message from a serving cell for uplink transmission and use the corresponding TA that is maintained either via initial acquisition or subsequent  update from the network.

[0109] For the mTRP situation, as such, a serving cell may potentially use multiple TRP to serve the UE. The multiple TRPs may be characterized by distinct TAs and thus the TRPs may need to be associated with multiple TAGs. As such, in comparison to single TRP situation, a cell having mTRPs may need to be associated with multiple TAGs in order for the UE to correctly apply the TA when mTRP service is provided.

[0110] In some example implementations, there may be two TAGs for serving the UE. These two TAGs may be associated with two sets of TRPs and each eat of TRPs may be associated with a TA, of two TAs (2TA) .

[0111] In order for the UE to perform uplink communication with a TRP, the TA must be known to the UE. For performing a cell switch to a target cell involving a particular TRP, including in LTM and CLTM cell switches, the UE would need to obtain / determine the TA associated with the particular TRP.

[0112] Early Synchronization in LTM with mTRPs and 2TA

[0113] As examples, downlink and uplink synchronization between the UE and a serving cell may be achieved via information provided by Transmission Configuration Indicator (TCI) and a known TA, respectively. For LTM, early synchronization may be performed between the UE and a candidate cell via the serving cell, so as to reduce synchronization latency when cell switch does occur, as indicated in the procedure A1 and B1 in FIG. 5 and FIG. 6, respectively.

[0114] In some implementations of LTM, such early synchronization procedure may include preforming activation / deactivation of TCI states for the candidate cell at the UE by the serving cells (e.g., for DL synchronization) and early RACH procedures between the UE and the candidate cells (e.g., for UL synchronization) prior to the LTM execution. For example, for early downlink synchronization, the TCI state for each candidate cell may be activated for the UE prior to cell switch of the LTM execution steps in FIG. 5 and FIG. 6. For another example, for uplink synchronization, earlier time advance (TA) determination or acquisition may be performed by the UE for each candidate cell prior to the cell switch of the LTM of FIG.  5 and FIG. 6.

[0115] In the situation where the LTM or CLTM co-exists with the mTRP in a candidate cell and where multiple TAs (e.g., 2TA) may be involved, the early DL and UL synchronization with such a candidate cell may need to be implemented by taking into consideration the mTRP or even the mTRP with 2TA.

[0116] For a candidate cell configured with mTRP, a multiple Downlink Control Information (mDCI) mechanism may be used for scheduling the downlink resources in the candidate cell when performing downlink communication with the UE, where the mTRPs may be scheduled by separate DCIs in separate multiple Physical Downlink Control Channels (mPDCCHs) . In such example implementations, for early downlink synchronization purposes in LTM or CLTM, the activation of TCI states with respect by such a candidate cell may be provided to the UE via a MAC control element (MAC CE) . Such a MAC CE, for example, may be transmitted from the serving cell to inform the UE of TCI State IDs for activating TCI states associated with a candidate cell prior to the cell switch, and at the same time. The serving cell may further indicate a control resource set (CORESET) pool associated with the TCI states for activation in such a MAC CE, as shown in FIG. 7. The CORESET Pool may be indicated by the CORESET POOL ID shown in the example MAC CE of FIG. 7. The CORESET POOL ID may correspond to a particular TRP of the mTRPs of the candidate cell (indicating the TRP that the CORESET with the CORESET ID belongs to) and may further correspond to a particular PDCCH of the mPDCCHs having a particular TA. In some example implementations, the UE may consider that all TCI state IDs that are activated by the MAC CE for the TRP are indicated by CORESETPOOLID =0 or CORESETPOLLID=1 in the MAC CE if there are two different values of CORESETPOOLID being configured for the candidate cell.

[0117] For some candidate cells configured with mTRP, an alternative single DCI mechanism may be used, in which the scheduling to the downlink transmission for the multiple TRPs may be scheduled by one single DCI transmitted via PDCCH. In such implementations, the MAC CE for TCI state activation above may be adapted to indicate different sets of TCI states associated with each codepoint of DCI. In each TCI state set contained in the MAC CE, at most 4 TCI states may be provided (such as in FIG. 8) . In one implementation, as shown in  FIG. 8, the candidate cell may be configured with mTRP with a Joint mode. In the joint mode mTRP, one TCI state can be used for UL and DL transmission simultaneously, with “Fi, 1” fields of FIG. 8 being included to indicate whether the first Joint TCI state for the i-th code point is present in the MAC CE or not (e.g., Fi, 1 = 1 indicates a presence of the first Joint TCI state for the i-th code point, whereas Fi, 1 = 0 indicates an absence of the first Joint TCI state for the i-th code point) , and Fi, 2 filed of FIG. 8 being included to indicate whether the second Joint TCI state for the i-th code point is present in the MAC CE or not. The Si, j fields in FIG. 8 in such implementations may be considered as reserved bits (e.g., always set to 0) . The candidate cell may be alternatively configured with mTRP in a Separate mode. In the Separate mode mTRP, one TCI state may only be used for either UL transmission or DL transmission, with the Fi, j fields of FIG. 8 being associated with DL transmission to indicate whether the TCI state Id fields for the i-th codepoint and the j-th TRP are provided in the MAC CE or not and the provided TCI state Ids are for DL transmission, and with the Si, j fields of FIG. 8 being associated with UL transmission to indicate whether the TCI state Id fields for the i-th codepoint and the j-th TRP are provided in the MAC CE or not for UL transmission..

[0118] Scheduling Request (SR) handling during an ongoing RACH-less LTM

[0119] In some situations, an SR may be triggered during ongoing RACH-less LTM duration, and the RACH procedure may be triggered in at least one of the following cases:

[0120] ● Case 1: where there is no available PUCCH resources that can be used for the pending SR.

[0121] ● Case 2: when the SR_COUNTER of the pending SR is equal to or greater than a predefined maximum value (e.g. sr-TransMax) .

[0122] However, the RACH triggered by SR during the online RACH-less LTM will violate the ‘rach-less’ designation. So, in order to avoid triggering the RACH procedure during the ongoing RACH-less LTM:

[0123] ● In some example implementations, the RACH triggered by SR due to at least one of the above two cases may not be initiated if there is an ongoing RACH-less LTM. In such implementations, the SR may be still pending or the corresponding  SR_COUNTER may be still equal or greater than a predefined maximum value as soon as the ongoing RACH-less LTM is successfully terminated. For avoiding triggering the RACH by the SR once the RACH-less LTM is successfully terminated, for one example, the pending SR may be canceled if there is no available PUCCH resources for the pending SR and if the RACH-less LTM is successfully terminated, and for another example, the SR_COUNTER for a pending SR may be set to 0 if the RACH-less LTM is successfully terminated.

[0124] ● In some example implementations, the SR may not be considered as pending if RACH-less LTM is ongoing and an SR is triggered. In such implementations, the SR may not be associated with any PUCCH resources.

[0125] ● In some other example implementations, an SR may not be triggered if RACH-less LTM is ongoing. In some situations, there may be no available PUCCH resources that can be used for the transmission of the SR. In such situations, an SR may not be triggered if there is BFR being triggered for at least one serving cell and a RACH-less LTM is ongoing. In such implementations, an SR may not be triggered if there is a regular BSR and / or periodic BSR being triggered and a RACH-less LTM is ongoing.

[0126] Communication of Activated TCI States of Source Cell to Target Cell

[0127] In some situations, in order to reduce a transmission delay caused by taking measurements for the Modulation Coding Scheme (MCS) determination. The target NG-RAN or DU for cell switch in LTM or CLTM may need to be aware of all the TCI states activated by the source DU or NG-RAN. To inform the target NG-RAN or DU of the currently activated TCI states at the source cell prior to the cell switch so that the target NG-RAN or DU can use such information for scheduling the UL / DL transmission subsequent to the Cell switch, the source DU / NG-RAN may be configured to forward such activated TCI states to the target DU / NG-RAN via inter cell messaging.

[0128] For inter-DU LTM or CLTM within the same CU, for example, activated TCI state list at the source cell may be first forwarded from the source DU to the CU using a DU-CU  message such as a DU-CU CELL SWITCH NOTIFICATION message, as shown in FIG. 9, followed by the CU forwarding the TCI state list for the activated TCI states at the source cell to the target DU via a CU-DU message such as a CU-DU CELL SWITCH NOTIFICATION message, as shown in FIG. 10.

[0129] For inter NG-RAN LTM or CLTM (inter-CU LTM or CLTM) , the TCI state list may first be forwarded from the source DU to the source CU, similar to FIG. 9, followed by being forwarded from source CU to the target CU via, for example, an LTM CELL SWITCH NOTIFICATION message, as shown in FIG. 11, and then followed by being forward from the target CU to the target DU, similar to FIG. 10. Thus, in addition to the CU-DU Message and DU-CU Message used for intra-CU LTM or CLTM, one more inter-node or inter-CU message may be needed.

[0130] In one example implementation, the information elements for the activated TCI State List above may include but are not limited to at most 8 elements, each element including one mandatory IE Joint or DL TCI State ID and one optional IE UL TCI State ID.

[0131] UE-Based TA measurement for UL Synchronization in Inter-CU LTM or CLTM

[0132] In some example implementations of LTM or CLTM, TA measurement of candidate or target cell may be performed by the UE for uplink synchronization. Such measurements may be referred to as UE-based TA measurements. UE-based TA measurements of a candidate or target cell, for example, may be based on measuring arrival time difference between reference signals from the candidate or target cell and the current source serving cell. Then the TA for the candidate or target cell may be derived from such measurements and the known TA for the source cell.

[0133] Such derivation of candidate or target cell TAs, however, is based on that the source cell and the candidate or target cell having identical or similar time reference. Such an assumption, may usually hold true in intra-CU LTM or CLTM situations, but may be off, sometimes significantly, in inter-CU LTM or CLTM situations.

[0134] In some example implementations, for UE based TA measurement in the inter-CU LTM case, an identification scheme for the TA measurements may be used by the source CU in  order to group the measured information items related to TAs with like time bases. For example, CU-CU interactions may be established between the source CU and candidate / target CUs in order for the candidate / target CUs to provide time synchronization information for all its candidate cells to the source CU. The source CU may then derive / assign / allocate identification for UE-based TA measurements based on like time basis, and forward the measurement identifications to the candidate / target CUs. TA measurements with a same measurement ID would be considered as having the same time basis and thus the derivation of TA for corresponding candidate or target cell based on such UE-based measurement would be considered valid. For a specific example, for UE to determine whether the TA of candidate cell can be measured, UE may be provided with the measurement Id for the serving cell and each candidate cell respectively, e.g., ltm-UE-MeasuredTA-ID-r18 and ltm-ServingCellUE-MeasuredTA-ID. Such IDs may be assigned / allocated to the measurements by the source DU according to the synchronization information provided from candidate CUs.

[0135] In some alternative implementations of the above, the measurement ID determination and assignment may be performed by a core network node. In such implementations, the CUs may be configured to inform the core network of the time synchronization information rather than inter-CU in order for the core network to perform the measurement ID determination and assignment / allocation.

[0136] In some other example implementations, UE-based TA measurement may be disallowed for inter-CU LTM or CLTM. In other words, the TA for a candidate cell would be obtained using other means (e.g., via a RACH procedure having RAR (Random Access Response) containing a TA) rather than via UE-based measurements when the candidate cell is in a CU different from the CU for the current serving cell.

[0137] For example, a CU Identifier may be introduced. Then the UE based TA measurement may be allowed for a candidate cell if the CU identifier of the candidate cell matches a stored CU Identifier of the current serving cell of the source CU, and the measurement ID for the candidate cell, e.g., ltm-UE-MeasureTA-ID for the candidate cell, also matches a stored measurement ID for the current serving cell, e.g.,  ltm-ServingCellUE-MeasuredTA-ID of the serving cell (the matching of the measurement IDs would indicate that similar time basis for deriving the candidate TA from the measurements, as described above) .

[0138] For inter LTM or CLTM with candidate cells having multiple TRPs and multiple TA (e.g., 2TA) , one example option is to disallow UE-based TA measurement for such candidate cells. In some other example implementations, such UE-base TA measurements may be allowed with the mTRP and multiple TAs taken into consideration.

[0139] For example, a mapping relationship between SSB / CSI-RS and TAG information for a candidate cell configured with multiple TAGs (e.g., two TAGs) may be introduced. The measurements of the SSB / CSI-RS would thus be tied with the multiple TAGs of the candidate cell and thus allowing for derivation of the multiple TAs from the UE-based measurements.

[0140] In some example implementations for SSB type reference signal, SSBs of the candidate cell may be divided into two groups, with one group referred to as ssb--PositionInBurstForTag which indicates the SSB index for the first TAG, and the other group referred to as ssb-PositionInBurstForTag2 which indicates the SSB index for the second TAG. In each group, one bitmap type parameter may indicate a presence of the SSB. For the bitmap indicated by the ssb-PositionInBurstForTag, the SSB may be indexed in ascending order from 0 and up, whereas for the bitmap indicated by the ssb-PositionInBurstForTag2, the SSB may be indexed in ascending order from the largest SSB index according to the ssb-PositionInBurstForTAG plus 1. In some other example implementations for SSB type reference signal, an information element SSB-Tag may be introduced for a candidate cell whose value may be an SSB-Id. TA information for the first TAG indicated by tag-Id or tag2-Id of the candidate cell would be obtained if the UE based TA measurement is performed based on the SSB with an index that is equal to or less than the SSB-Id indicated by the SSB-Tag. TA information for the second TAG indicated by tag2-Id or tag-Id of the candidate cell would be obtained if the UE based TA measurement is performed based on the SSB with an index that is equal to or greater than the SSB-Id indicated by SSB-Tag. In some example implementations of CSI-RS, one Tag indication may be added into or associated with one CSI-RS resource set configuration for indicating the TAG information for all the CSI-RS  resources in the resource set. In some other implementations of CSI-RS, one TAG indication may be added into or associated with one CSI-RS resource configuration for indicating the TAG information of the CSI-RS resource.

[0141] Event-triggered L1 Measurement Report

[0142] For event-triggered L1 measurement report, the corresponding measurement resources may include one or more beams from one or more candidate cells in one resource set, e.g., the CSI resource configuration. But the NW may want to make the LTM event only applicable to some specific beams or cells in the resource set. In addition, the current CSI resource configuration list may be common for all candidate cells, e.g., the UE may use the common CSI resource configuration list for L1 measurement in the subsequent LTM. But the candidate beams or cells to be measured / reported may be changed when the UE switches to different candidate cells, e.g., only some specific neighbor beams / cells may be considered. It would be beneficial to provide the allowed / excluded cell and / or beam list for the L1 measurement, to allow the UE to report L1 measurements only for some specific cells and / or beams, so as to avoid the unnecessary measurement reporting. Further, the cell specific offset and / or beam specific offset can be used for event-triggered L1 measurement report, to allow the flexible adjustment of the event threshold applicable to different beams or cells.

[0143] For event-triggered L1 measurement report, the measurement resource configuration and / or measurement report configuration may include at least one of the following information:

[0144] ● a list of cells allowed for event-triggered measurement, e.g., each cell may be identified by a PCI or an LTM candidate configuration ID (e.g., ltm-CandidateId) . The UE may only measure the indicated cell (s) in the list, trigger the measurement report for the indicated cell (s) , and / or include the measurement results of the indicated cell (s) in the measurement report.

[0145] ● a list of cells excluded for event-triggered measurement. The UE may not measure the indicated cell (s) in the list, not trigger the measurement report for the indicated cell (s) , and / or not include the measurement results of the indicated cell (s) in the measurement report.

[0146] ● a list of beams / RSs allowed for event-triggered measurement, e.g., each beam / RS may be identified by an SSB index, or a CSI-RS index. The NW may configure the SSB list and CSI-RS list separately. The UE may only measure the indicated beam / RS (s) in the list, trigger the measurement report for the indicated beam / RS (s) , and / or include the measurement results of the indicated beam / RS (s) in the measurement report.

[0147] ● a list of beams / RSs excluded for event-triggered measurement. The NW may configure the SSB list and CSI-RS list separately. The UE may not measure the indicated beam / RS (s) in the list, not trigger the measurement report for the indicated beam / RS (s) , and / or not include the measurement results of the indicated beam / RS (s) in the measurement report.

[0148] ● a list of cell specific offset, e.g., each item in the list may include a cell ID (e.g., PCI+frequency, PCI or an LTM candidate configuration ID) and the corresponding cell specific offset applicable to the cell.

[0149] ● a list of beam / RS specific offset, e.g., each item in the list may include a beam / RS ID (e.g., an SSB index, or a CSI-RS index) and the corresponding beam / RS specific offset applicable to the beam / RS.

[0150] The cell specific offset, beam / RS specific offset may include L1-RSRP, L1-RSRQ, or L1-SINR value.

[0151] If the same information / item above is included in both the measurement resource configuration and the associated measurement report configuration, the UE may perform the following option:

[0152] ● Option 1: ignore the information / item in the measurement resource configuration, i.e. only consider the information / item in the measurement report configuration;

[0153] ● Option 2: combine the value of the information / item in the measurement resource configuration with that in the measurement report configuration for the same cell / beam, and use the combined value (e.g. value 1 in the measurement resource configuration plus value 2 in the measurement report configuration) .

[0154] Inter-Node Coordination on L1 Measurement for LTM

[0155] In some implementations, MCG LTM and SCG LTM can be configured simultaneously in NR-DC. So, the L1 measurement for MCG LTM and SCG LTM can also be provided simultaneously. Since the L1 measurement for MCG LTM and SCG LTM is configured by the MN and the SN independently, the MN and the SN need to coordinate the maximum number of L1 measurement resources / configurations that the SN is allowed to configure for L1 measurement, in order to ensure that UE capabilities are not exceeded.

[0156] The MN may indicate the maximum number of L1 measurement related resources / configurations the SN is allowed to configure, e.g., via CG-ConfigInfo message, including at least one of the following information:

[0157] ● The max number of frequency layers that the UE can measure for intra-and inter-frequency without measurement gaps L1-RSRP measurement;

[0158] ● The max number of frequency layers that the UE can measure for inter-frequency L1-RSRP measurement with measurement gaps;

[0159] ● The max number of neighbor cells that the UE can measure for L1-RSRP per frequency layer for intra-frequency or inter-frequency without measurement gaps;

[0160] ● The max number of neighbor cells that the UE can measure for L1-RSRP per frequency layer for inter-frequency with measurement gaps;

[0161] ● The max number of total cells of serving cells and neighboring cells across all frequency layers of intra-frequency and inter-frequency without measurement gaps for L1 measurement;

[0162] ● The max number of SSB resources for L1-RSRP measurement that the UE can measure within a slot across candidate cells for intra-and inter-frequency without gap L1-RSRP measurement;

[0163] ● The max number of SSB resources that the UE can measure for L1-RSRP per frequency layer for intra-frequency or inter-frequency without measurement gaps;

[0164] ● The max number of SSB resources that the UE can measure for L1-RSRP per frequency layer for inter-frequency with measurement gaps;

[0165] ● The max number of total SSB resources of serving cells and neighboring cells across all frequency layers of intra-frequency and inter-frequency without measurement gaps for L1 measurement;

[0166] ● Maximum number of RRC configured candidate cells for intra-frequency L1-RSRP measurement;

[0167] ● Maximum number of aperiodic LTM CSI report configurations (configs)

[0168] ● Maximum number of periodic LTM CSI Report Configurations;

[0169] ● Maximum number of semi-persistent LTM CSI report configurations;

[0170] ● Maximum number of RRC configured candidate cells for intra-and inter-frequency L1-RSRP measurement.

[0171] In some example embodiments, if the item / information above is absent in the inter-node message from the MN to the SN (e.g., CG-ConfigInfo) , the SN is not allowed to configure the corresponding configurations / resources for L1 measurement, or the SN is allowed to configure the corresponding configurations / resources for L1 measurement up to the maximum value.

[0172] In some embodiments, the SN can also request the MN for new maximum values of the number of L1 measurement related configurations / resources (e.g., as listed above) that the SN can configure, e.g. via CG-Config message. It can be up to the MN whether to accommodate the SN request. In some example embodiments, the capabilities across MCG and SCG per frequency layer, e.g., may include:

[0173] ● The max number of neighbor cells that UE can measure for L1-RSRP per frequency layer for intra-frequency or inter-frequency without measurement gaps;

[0174] ● The max number of neighbor cells that the UE can measure for L1-RSRP per frequency layer for inter-frequency with measurement gaps;

[0175] ● The max number of SSB resources that the UE can measure for L1-RSRP per frequency layer for intra-frequency or inter-frequency without measurement gaps;

[0176] ● The max number of SSB resources that the UE can measure for L1-RSRP per frequency layer for inter-frequency with measurement gaps.

[0177] In some example implementations, the following options can be considered for the coordination:

[0178] ● Option 1: the MN may indicate a hard-split value of the maximum number of resources per frequency that the SN is allowed to configure. The SN can request the MN for a new maximum value of the number that the SN can configure.

[0179] ● Option 2: Based on option 1, the MN and the SN may further exchange the frequency layer information configured for LTM by each node. The value indicated by the MN may only be applicable to frequency layers where both the MN and the SN configures LTM.

[0180] Regarding how to exchange the frequency layer information configured for LTM by each node, two options can be considered:

[0181] ● Option 1: introducing an indication for the L3 frequency information (e.g., frequency listed in the measuredFrequenciesMN, measuredFrequenciesSN) to indicate whether LTM is configured in this frequency.

[0182] ● Option 2: introducing a list of frequency information where LTM is configured by the MN in each frequency, e.g., included in the CG-ConfigInfo message; and / or a list of frequency information where LTM is configured by the SN in each frequency, e.g., included in the CG-Config message.

[0183] It should be noted that UE capabilities discussed above may be defined per BC. In principle, the UE can report different values for different BCs. According to the current inter-node coordination, the MN can indicate the allowed BC list (e.g., allowedBC-ListMRDC) to the SN, and the SN shall inform the selected BC (e.g., selectedBandCombination) to the MN. But the SN may change its band combination during RRC connection state, and if the MN  wants to indicate new values for the newly selected BC, it is possible the SN has to reconfigure the physical resources according to the new indicated value, this causes more complexity to MN / SN signaling.

[0184] Regarding how to indicate the value for per-BC capabilities, e.g., as listed above, two options can be considered:

[0185] ● Option 1: The MN may indicate a single value for each coordinated capability to the SN, and vice versa. The value may be applicable to all BCs in the allowed BC list (e.g. from the MN to the SN) or requested BC (e.g., from the SN to the MN) ;

[0186] ● Option 2: The MN may indicate the value for each coordinated capability per BC in the allowed BC list, and vice versa. For example, for each BC in the allowed BC list from the MN to the SN, the MN can indicate a value for each coordinated capability. For the requested BC from the SN to the MN, if any, the SN can request a value for each coordinated capability.

[0187] Early Data / Status Transfer in CLTM

[0188] Early data / status transfer may be implemented in a conditional handover, including CLTM (particular in inter-CU CLTM) in order to anticipate cell switches and to reduce latency by forwarding data / status for the UE (e.g., for downlink) from the source cell to the target cell prior to the actual cell switch.

[0189] In some example implementations of conditional handover (CHO) , it may be up to the NW to decide when to initiate such early status transfer and early data forwarding. However, the NW may not be aware of when UE may detach from the source NG-RAN. As such, there may be a situation where the target NG-RAN may send early Service Data Units (SDUs) received from source NG-RAN to the UE starting with an SN number received in the early status transfer from the source NG-RAN but most of the early SDUs may have been successfully transferred to the UE by source NG-RAN. For the SDUs from Acknowledgment Mode (AM) Data Radio Bearer (DRB) , the target NG-RAN can be configured to discard the already received early SDUs from source NG-RAN according to a status report from the UE as triggered by a Package Data Convergence Protocol (PDCP) re-establishment. However, for  the early SDUs received from Un-acknowledgment Mode (UM) DRB, the target NG-RAN may not be aware of which of those downlink early SDUs received from target NG-RAN have been successfully sent to UE due to the lack of status report from UE for UM DRB, and as a result, the target NG-RAN would not discard these SDUs already-received from source NG-RAN and would transmit them after the cell-switch, thereby increasing the early DL SDU transmission delay by the redundant transmission of the already-received SDUs.

[0190] In some example implementations for reducing or avoiding such redundancy and transmission delay, the source NG-RAN may be triggered to transfer DL SN of the first unreceived SDUs to the target NG-RAN via early status transfer when the UE detaches from the source NG-RAN. For example, the source NG-RAN may be triggered to perform such transfer by being informed by the UE of the detachment. Example steps of such implementations may include:

[0191] ● STEP 1: The UE may send a ‘good-bye’ message to the source cell when detaching from the source NG-RAN (e.g., upon CLTM cell switch determination) .

[0192] ● STEP 2: When receiving the ‘good-bye’ message from the UE, the source NG-RAN may trigger and transfer an early status transfer message with a DISCARD DL COUNTER VALUE to the target NG-RAN to indicate the SN or COUNTER number of the first SDU that has not been sent to UE or that has not been successfully sent to UE.

[0193] ● STEP 3: The target NG-RAN may discard the PDCP SDUs with a SN or COUNTER number that is less than the DISCARD DL COUNTER VALUE.

[0194] In STEP 1, the ‘good-bye’ message may be an RRC signaling, or a UL MAC CE, a UCI message. In this message, at least one of the following information may be contained:

[0195] ● Target cell information, to indicate the information of the target cell which the UE decides to switch to. The target cell information can be indicated via candidate cell Id.

[0196] ● TCI state information, to indicate the information of the beam that would be used for UE to perform the UL transmission and / or DL transmission on the target cell.

[0197] In some other example implementations for reducing or avoiding such redundancy and transmission delay, the UE may be configured to transfer a status report directly to the candidate cell after cell switching to the candidate cell. Example steps may of such implementations may include:

[0198] ● STEP 1: The UE may store a COUNTER / SN number of a first SDU for a DRB that has not been received from source NG-RAN and / or the corresponding DRB ID when detaching from it.

[0199] ● STEP 2: UE may send the COUNTER / SN number of a first SDU for the DRB to the target Cell during an on-going CLTM cell switch or when CLTM cell switch is considered as successful.

[0200] ● STEP 3 including example alternatives of:

[0201] ○ STEP 3a: In one implementation of step 3, The PDCP entity may trigger and generate one PDCP control PDU to include the COUNTER or SN number that has been stored in STEP 1 when and after performing a PDCP re-establishment procedure triggered by CLTM Cell switch.

[0202] ○ STEP 3b: In another implementation of STEP 3, the RRC layer may generate an RRC message (e.g., RRCReconfigurationComplete) to include the COUNTER or SN number and corresponding DRB ID that has been stored in STEP 1.

[0203] ● STEP 4: The target NG-RAN may discard the received early SDUs from the source NG-RAN whose COUNTER / SN numbers or COUNTER / SN numbers are less than the COUNTER / SN number received from UE.

[0204] Early DL synchronization Procedure with Co-Existence of LTM and CLTM

[0205] As described above, early DL synchronization procedure (e.g., A1 of FIG. 5 and B1 of FIG. 6) may be performed via candidate cell TCI state activation / deactivation MAC CE. Assuming a coexistence between CLTM and LTM, for early DL sync, early DL synchronization may need be harmonized between LTM and CLTM. In particular, for LTM,  the cell switch determination and triggering are performed from the network side. As such, the network determines early activation of TCI states accordingly via the TCI state activation / deactivation MAC CE. For CLTM, the determination of cell-switch condition and cell-switch is made by the UE and thus adding complexity to early synchronization via network-side TCI state activation / deactivation MAC CE.

[0206] In some example implementations, the NW may indicate to the UE the TCI states for a candidate cell via TCI state activation / deactivation MAC CE for early DL sync (as used for downlink synchronization in LTM) , and UE may select the SSB / CSI-RS / TCI state among the activated TCI states indicated by TCI state activation / deactivation MAC CE, if any, for CLTM Cell switch determination if the candidate cell is determined as the target cell to switch to.

[0207] In some other example implementations, for CLTM, instead of having the candidate / target cell sending the TCI state activation / deactivation MAC CE, the UE may fist select TCI states according to, for example, L1 measurement for early DL sync, and then inform serving cell and / or candidate / target cell of the activated TCI states via a UL signaling. In one implementation, the UL signaling may be an RRC message, or UL MAC CE, or UCI. In case of the UL signaling being an RRC message, the RRC message may be an RRCReconfigurationComplete message which is response to the RRCReconfiguration Message for CLTM Cell switch. In the case of the UL signaling being a UL MAC CE, the UL MAC CE may be generated when TSR (TCI State Reporting) is triggered and pending by the CLTM Cell switch. The pending TSR may be canceled by at least one of the following events: 1) successful completion of the CLMT Cell switch; 2) The UL MAC CE being included into a MAC PDU and / or transmitted.

[0208] For example, such a UL signaling may contain but is not limited to at least one of: (1) UL / DL / Joint TCI State for indicating the UL / DL / Joint TCI state that has been activated; and / or (2) a code point field Pi for indicating the codepoint of a DCI for the present UL / DL / Joint TCI state. A UL MAC CE example of UL signaling is illustrated in FIG. 12.

[0209] Early UL Synchronization Procedure with Co-Existence of LTM and CLTM

[0210] In LTM, where evaluation and determination of cell switch is performed on the  network side, UL synchronization between the UE and a candidate / target cell may be performed via PDCCH ordered RACH procedure. For CLTM, an early RACH procedure may still be supported for reducing the cell switch delay, but via a RACH procedure initiated by the UE. Such early RACH requested by UE may be appropriate for CLTM since both the target cell and the condition / timing of Cell switch are evaluated / determined by UE itself. The following example implementations may be considered for early UL synchronization with LTM and CLTM co-existence.

[0211] PDCCH Ordered RACH

[0212] In a normal PDCCH ordered early RACH procedure, there may not be any RAR present. The TA value, instead of being provided to the UE via RAR, may be stored at the serving DU and / or forward to the serving CU, and then forwarded to the UE by using the LTM Cell switch MAC CE, in, for example, an inter-DU LTM. However, such an LTM cell switch MAC CE is not present in CLTM. As such, to use PDCCH ordered early RACH procedure for CLTM, the TA value would need to be forwarded to the UE prior to the cell switch in another manner. As an additional reason that ordinary PDCCH ordered early RACH procedure may not be ideal for CLTM as compared to LTM, an LTM Cell switch is generally actively triggered by the NW. So, it is natural that the NW would determine which candidate cell UE should obtain the early TA for. On the other hand, for CLTM, it is up to UE to decide the candidate cell to switch to, and in this sense, it is rational to let UE decide for which candidate cell the early TA shall be obtained.

[0213] As such, in some example implementations, to support TA acquisition prior to the cell switch via PDCCH ordered RACH in CLTM where LTM cell switch MAC CE is not present, an RAR may be incorporated into the early PDCCH ordered RACH. In such implementations, the TA value of the candidate cell may be informed to UE by using the RAR of the modified PDCCH ordered RACH procedure.

[0214] In some other example implementations, a separate DL MAC CE may be introduced that follows the early PDCCH ordered RACH to inform UE of the TA value for the candidate cells where the early RACH has been performed.

[0215] UE-Triggered RACH

[0216] Consistent with that the CLTM is evaluated and determined by the UE, the early RACH procedure may be actively triggered and initiated by the UE to each of the candidate. In some example implementations, a message for requesting early RACH may be introduced which may be sent from UE to serving cell to request initialization of early RACH, which may then be ordered by the network via PDCCH. In some other example implementations, the early RACH procedure may be directly triggered by MAC entity itself in the UE.

[0217] In some example implementations, the UE requested and network ordered early RACH procedure may incorporate an RAR response from the network so that the TA is provided to the UE, particularly for CLTM where there is no LTM cell switch MAC CE that can carry the TA. An example procedure is shown in FIG. 13 and may include but is not limited to the following steps:

[0218] ● STEP 1: The UE may send an early RACH request message to the serving cell for initiating an early RACH procedure to a candidate cell.

[0219] ● STEP 2: The UE may receive a PDCCH order for early RACH and determine to initiate a RACH procedure with RAR present in response to the received PDCCH.

[0220] ● STEP 3: UE may select an SSB ID, preamble Id, RO according to the PDCCH order to perform the RACH procedure.

[0221] ● STEP 4: UE may receive the RAR and perform the TA maintenance for the candidate cell if the RAR is successfully decoded and the preamble ID in RAR matches the preamble ID indicated by PDCCH order. This step may be implemented with the following alternatives:

[0222] ○ STEP 4a: During an RA-Response Window, the UE may monitor the PDCCH for RAR reception on the serving cell to obtain the TA information of the candidate cell from RAR; or

[0223] ○ STEP 4b: During the RA-Response Window, the UE may monitor the PDCCH for RAR reception on the candidate cell to obtain the TA  information of the candidate cell.

[0224] ● STEP 5: the UE may perform the TA maintenance if the TA has been successfully obtained from RAR.

[0225] In some example implementations of STEP 1 of FIG. 13 above, the early RACH request may be implemented as a UL RRC message, e.g., UE assistance information. Alternatively, the early RACH request may be implemented as a UL MAC CE. In case of the early RACH request being a UL MAC CE, in some examples, one Scheduling Request (SR) may be triggered if the early RACH request MAC CE is generated and there is no valid PUSCH that can be used for transmission of such UL MAC CE. In some example implementations, the early RACH request message may include but is not limited to at least one of:

[0226] ● candidate Cell information to indicate one or more candidate cells that UE want to obtain the early TA; or

[0227] ● Priority indication to indicate the priority of each present candidate cell in the early RACH request.

[0228] In some example implementations, the early RACH request may be triggered by the at least one of the following events:

[0229] ● The measurement event for one or more candidate cells are met. For example, the UE may perform the measurement on the serving cell and / or the candidate cell to decide whether the measurement event is met or not. If the event is met, then the UE may decide to trigger the early RACH request.

[0230] ● When there is no UL data waiting for the transmission in a buffer.

[0231] ● When there is no DL data waiting for the re-transmission in a HARQ buffer.

[0232] ● When there is no other MAC procedure defined in the MAC spec is considered as pending.

[0233] ● When the prohibit timer for the early RACH request is not running.

[0234] In some example implementations, the early RACH request may be triggered and  pending per candidate cell. In another implementation, the early RACH request may be triggered and pending per MAC entity. In yet another implementation, the early RACH request may be triggered and pending as per UE.

[0235] In some example implementations of early RACH request, there may be a prohibit timer to prevent UE from frequently triggering the early RACH request. The early RACH request may not be allowed during the running period of the prohibit timer. In one implementation of the prohibit timer, the prohibit timer may be configured per candidate cell, or per MAC entity, or per UE. In one example implementation of the prohibit timer, the prohibit timer may be started / restarted by the transmission of the early RACH request. In one example implementation of the prohibit timer, the prohibit timer may be stopped by at least one of the following events:

[0236] ● A successful CLTM Cell switch.

[0237] ● When the PDCCH order for early RACH has been received and the candidate cell indicated by PDCCH order belongs to at least one of the indicated candidate cells in the previous early RACH request message.

[0238] In some example implementations of early RACH request, the pending early RACH request may be cancelled by at least one of the following events:

[0239] ● A measurement event for CLTM Cell switch is met

[0240] ● When CLTM Cell switch is executed

[0241] ● When the early RACH request message has been transmitted

[0242] In some example implementations of STEP 2 of FIG. 13 above, to distinguish between PDCCH ordered RACH with RAR present and the one without RAR present for LTM and CLTM respectively, at least one of the following methods may be adopted:

[0243] ● Solution 1: a one-bit-flag may be introduced into the DCI (the PDCCH order) to indicate whether the RAR is present for the RACH triggered by such a DCI for the indicated candidate cell.

[0244] ● Solution 2: it may be determined that the RAR is present for the early RACH toward a candidate cell if the candidate cell is configured only for CLTM.

[0245] ● Solution 3: it may be determined that the RAR is present for the early RACH toward a candidate cell if one predefined flag is set to true in an early RACH configuration of the candidate cell.

[0246] In some example implementations of STEP 3 of FIG. 13 above, the UE is normally located at the edge of a candidate cell when performing early RACH toward it. As such, to improve the success rate of the early RACH, repetition of MSG. 1 of the early RACH procedure may be supported. In some example implementations, the RACH preamble repetition number may be configured in the early RACH configuration for the candidate cell. In some other example implementations, the preamble repetition number may be indicated in the DCI (e.g., the PDCCH order) which triggers the early RACH.

[0247] In some example implementations of STEP 4 of FIG. 13 above, for both STEP 4a and STEP 4b, the RAR message for early RACH may be of at least one of the following formats:

[0248] ● A legacy RAR message;

[0249] ● A PDSCH transmission scheduled by the PDCCH which includes one DL MAC CE containing the TA information of the candidate cell. For example, the PDCCH may be addressed from C-RNTI. For another example, the PDCCH may be addressed from RA-RNTI.

[0250] For STEP 4a, for the serving cell to send the TA value to UE, the TA value, RA-RNTI, and / or corresponding Candidate cell ID may be sent from the candidate NG-RAN to serving NG-RAN via Xn interface for the inter-node CLTM.

[0251] In some example implementations of STEP 5 of FIG. 13 above, regarding the RACH success judgement, the RACH procedure may be considered as successful by at least one of the following non-limiting criteria:

[0252] ● An RAR is successfully decoded and the preamble ID indicated in received RAR  matches the PREAMBLE_ID while the ra-Response Window is running; and / or

[0253] ● A PDSCH is successfully decoded and there is a DL MAC CE that includes the TA information of the candidate cell indicated by the PDCCH order.

[0254] In the case that the RACH procedure is not successful, at least one of the following example actions may be adopted:

[0255] ● Re-transmission of the preamble with the same preamble Id indicated by PDCCH order may be implemented after a fallback time if the retransmission times does not reach a predefined maximum number of preamble retransmissions. The maximum number of preamble retransmission times may be indicated in PDCCH order or configured in the candidate cell configuration.

[0256] ● Consider the RACH procedure as terminated.

[0257] In some example implementations, the TA maintenance above for the candidate cell may include at least one of:

[0258] ● MAC layer informing the upper layer (e.g., RRC) the obtained TA value of the candidate cell and starting the TA Timer (TAT) corresponding to such candidate cell; and the RRC layer storing the TA value corresponding to the candidate cell in the UE variable. If the TAT corresponding to such candidate cell has expired, the MAC layer may inform the upper layer (e.g., RRC) to discard the respective TA value.

[0259] ● The MAC layer starting the TAT corresponding to the candidate TAG configured for the candidate cell if the TA value is obtained.

[0260] In some example implementations for early RACH procedure, as described above, the UE requested and network ordered early RACH procedure may not incorporate an RAR response from the network but a DL MAC CE may be introduced for informing the UE of the TA information of the candidate cell. An example implementation is illustrated in FIG. 14, which may include but is not limited to the following steps:

[0261] ● STEP 1: The UE may send a request message to the serving cell for initiating early  RACH procedure for a candidate cell.

[0262] ● STEP 2: The UE may receive a PDCCH order from serving cell to trigger the early RACH for the candidate cell.

[0263] ● STEP 3: UE may select the RACH resources to send the preamble toward the candidate cell according to the PDCCH order, and then consider the RACH procedure as complete.

[0264] ● STEP 4: The candidate cell may forward the TA information to the candidate cell.

[0265] ● STEP 5: Serving cell may forward the TA information corresponding to the candidate cell to the UE via a DL message.

[0266] ● STEP 6: UE may execute the TA maintenance for the obtained TA information corresponding to the candidate cell in STEP 5.

[0267] In some example implementations of STEP 1 of FIG. 13 above, the early RACH request may be implemented as a UL RRC message, e.g., UE assistance information. Alternatively, the early RACH request may be implemented as a UL MAC CE. In case of the early RACH request being a UL MAC CE, in some examples, one Scheduling Request (SR) may be triggered if the early RACH request MAC CE is generated and there is no available PUSCH that can be used for transmission of such UL MAC CE. In some example implementations, the early RACH request message may include but is not limited to at least one of:

[0268] ● Candidate Cell information to indicate one or more candidate cells that UE want to obtain the early TA; or

[0269] ● Priority indication to indicate the priority of each present candidate cell in the early RACH request.

[0270] In some example implementations, the early RACH request may be triggered by the at least one of the following events:

[0271] ● When a measurement events for one or more candidate cells are met. For example,  the UE may perform the measurements on the serving cell and / or the candidate cell to decide whether the measurement event is met or not. If the event is met, then UE may decide to trigger the early RACH request.

[0272] ● When there is no UL data waiting for the transmission in a buffer.

[0273] ● When there is no DL data waiting for the re-transmission in a HARQ buffer.

[0274] ● When there is no other MAC procedure defined in the MAC spec being considered as pending.

[0275] ● When the prohibit timer for the early RACH request is not running.

[0276] In some example implementations of early RACH request, the early RACH request may be triggered and pending per candidate cell. In another example implementation, the early RACH request may be triggered and pending per MAC entity. In yet another example implementation, the early RACH request may be triggered and pending as per UE.

[0277] In some example implementations of early RACH request, there may be a prohibit timer to prevent UE from frequently triggering the early RACH request. The early RACH request may not be allowed during the running period of the prohibit timer. In one example implementation of the prohibit timer, the prohibit timer may be configured per candidate cell, or per MAC entity, or per UE. In one example implementation of the prohibit timer, the prohibit timer may be started / restarted by the transmission of the early RACH request. In one example implementation of the prohibit timer, the prohibit timer may be stopped by at least one of the following events:

[0278] ● A successful CLTM Cell switch.

[0279] ● When the PDCCH order for early RACH has been received and the candidate cell indicated by PDCCH order is at least one of the indicated candidate cells in the previous early RACH request message.

[0280] In some example implementation of early RACH request, the pending early RACH request may be cancelled by at least one of the following events:

[0281] ● When measurement event for CLTM Cell switch is met.

[0282] ● When CLTM Cell switch is executed.

[0283] ● When the early RACH request message has been transmitted.

[0284] In some example implementations of STEP 3 of FIG. 14 above, the TA information and UE identity may be forwarded from the candidate cell to the serving cell.

[0285] In some example implementations of STEP 4 of FIG. 14 above, the TA information may be sent to UE from serving cell via a DL MAC CE (e.g., the candidate cell TAC MAC CE) in a PUSCH transmission. In some example implementations, the format of the candidate cell TAC MAC CE may follow the example implementation indicated in FIG. 15, including information elements including but not limited to:

[0286] ● CU identifier to indicate the CU information to which the candidate cell belongs;

[0287] ● Candidate cell ID to indicate the candidate cell for which the TA is provided in the MAC CE; and / or

[0288] ● TA command to indicate the absolute TA value of the candidate cell.

[0289] In some other example implementation, the format of the candidate cell TAC MAC CE may follow the implementation of FIG. 16.

[0290] In yet some other example implementations, the format of the candidate cell TAC MAC CE may follow the implementation of FIG. 17, where the each of the Ci fields represents one of the candidate cell. If the Ci field is set to 1, it indicates the corresponding TA value is provided in the MAC CE. The Timing Advance command field in FIG. 17 may be present sequentially in ascending order of i of the Ci files which are set to 1 in the MAC CE.

[0291] In some example implementations of STEP 5 of FIG. 14 above, for the TA maintenance for the candidate cell, the MAC layer may inform an upper layer (e.g., RRC) the obtained TA value of the candidate cell and start the TAT corresponding to such candidate cell. Then the upper layer, e.g., the RRC layer, may store the TA value corresponding to the candidate cell in the UE variable. If the TAT corresponding to such candidate cell has expired,  the MAC layer may inform the upper layer (e.g., the RRC) to discard the TA value corresponding to that candidate cell. In some other example implantations for TA maintenance for the candidate cell, the MAC layer may start the TAT corresponding to the candidate TAG configured for the candidate cell if the TA value is obtained.

[0292] Early RACH Triggered by MAC Entity

[0293] In some example implementations as described above, the early RACH may be triggered by a MAC entity rather than via PDCCH order. An example is illustrated in FIG. 18, which includes but is not limited to the following steps:

[0294] ● STEP 1: The serving cell may send an RRC configuration for early RACH for a candidate cell to the UE.

[0295] ● STEP 2: The UE may determine to initiate early RACH procedure to a candidate cell by some criteria, and perform a RACH initiation.

[0296] ● STEP 3: The UE may perform a RACH preamble transmission to the candidate cell.

[0297] ● STEP 4: The UE may then receive an RAR. Step 4 may include the following alternatives:

[0298] ○ STEP 4a: The UE may receive the RAR from serving cell.

[0299] ○ STEP 4b: UE may alternatively receive the RAR from candidate cell.

[0300] ● STEP 5: The UE may perform the TA maintenance if the RACH procedure is considered as successful.

[0301] In some example implementations of STEP 1 of FIG. 18 above, the early RACH configuration for the MAC entity initiated early RACH, for minimizing the detaching time of the serving cell, only Contention Free Random Access (CFRA) configuration may be applied for the MAC entity initiated early RACH.

[0302] In some example implementations of STEP 2 of FIG. 18 above, the UE may trigger the early RACH and select a candidate cell where the early RACH is performed by at least one of the following criteria:

[0303] ● When the measurement event for one or more candidate cells are met. For example, UE may perform the measurement on the serving cell and / or the candidate cell to decide whether the measurement event for initiating early RACH is met or not. If the event is met, then UE may decide to trigger the early RACH request.

[0304] ● When a prohibit timer is not running. Specifically, the prohibit timer for early RACH may be introduced to prevent the UE from frequently detaching from the current serving cell to perform the early RACH to the candidate cells. The UE may only initiate the early RACH if such a prohibit timer is not running. The UE may start the prohibit timer when initiating an early RACH procedure and the next early Rach procedure can only be initiated after this timer expires and is not running. In one implementation, a prohibit timer may be configured per candidate cell. In some other implementations, one prohibit timer may be configured for all candidate cells.

[0305] ● When the TA of the candidate cell have not been obtained or TA of the candidate cell have been obtained but the corresponding TAT has expired.

[0306] ● When there is no UL UP data waiting for the transmission in a buffer.

[0307] ● When there is no DL UP data waiting for the re-transmission in a HARQ buffer.

[0308] ● When there is no other MAC procedure defined in the MAC spec being considered as pending.

[0309] In some example implementations of STEP 4 of FIG. 18 above, for both STEP 4a and STEP 4b, the RAR message for early RACH may be of at least one of the following formats:

[0310] ● A legacy RAR message;

[0311] ● A PDSCH transmission scheduled by the PDCCH which includes one DL MAC CE containing the TA information of the candidate cell. For example, the PDCCH may be addressed from C-RNTI. For another example, the PDCCH may be addressed from RA-RNTI.

[0312] For STEP 4a, for the serving cell to send the TA value to UE, the TA value, RA-RNTI, and / or corresponding Candidate cell ID may be sent from the candidate NG-RAN to serving NG-RAN via Xn interface for the inter-node CLTM.

[0313] In some example implementations of STEP 5 of FIG. 18 above, regarding the RACH success judgement, the RACH procedure may be considered as successful by at least one of the following non-limiting criteria:

[0314] ● An RAR is successfully decoded and the preamble ID indicated in received RAR matches the PREAMBLE_ID while the ra-Response Window is running; and / or

[0315] ● A PDSCH is successfully decoded and there is a DL MAC CE that includes the TA information of the candidate cell indicated in the PDCCH order.

[0316] In the case that the RACH procedure is not successful, at least one of the following example actions may be adopted:

[0317] ● Re-transmitting the preamble that is selected upon the L1 measurement on SSB / CSI-RS may be implemented after a fallback time if the retransmission times of the preamble does not reach a predefined maximum number of preamble retransmissions. The maximum number of preamble retransmission times may be configured in the candidate cell configuration.

[0318] ● Consider the RACH procedure as terminated.

[0319] In some example implementations, the TA maintenance above for the candidate cell may include at least one of:

[0320] ● MAC layer informing the upper layer (e.g., RRC) the obtained TA value of the candidate cell and starting the TA Timer (TAT) corresponding to such candidate cell; and the RRC layer storing the TA value corresponding to the candidate cell in the UE variable. If the TAT corresponding to such candidate cell has expired, the MAC layer may inform the upper layer (e.g., RRC) to discard the respective TA value.

[0321] ● The MAC layer starting the TAT corresponding to the candidate TAG configured for  the candidate cell if the TA value is obtained.

[0322] CLTM Execution

[0323] In some example implementations, the CLTM execution procedure of FIG. 6 may be implemented according to the example in FIG. 19. The example CLTM execution procedure of FIG. 19 may include but is not limited to the following steps.

[0324] ● STEP 1: The UE may perform L1 / L3 measurements to evaluate the CLTM event (s) to determine whether a CLTM cell switch should be triggered or not.

[0325] ● STEP 2: The UE may generate and send a leaving indication to the serving cell if the event (s) for CLTM is / are evaluated as being met and there is at least one candidate cell that can be selected as the CLTM target cell.

[0326] ● STEP 3: The UE may receive the ACK and / or confirmation indication corresponding to the leaving indication.

[0327] ● STEP 4: The UE may perform L3 and / or L2 operations for CLTM Cell Switch Execution.

[0328] ● STEP 5: the UE may execute the CLTM Cell Switch to the selected CLTM candidate cell. STEP 5 may include the following alternatives:

[0329] ○ STEP 5a: The UE may initiate a RACH procedure for CLTM to the candidate cell.

[0330] ○ STEP 5b: The UE may generate a first UL transmission by using the configured grant to the candidate cell.

[0331] ● STEP 6: A CLTM Completion procedure is performed.

[0332] In some example implementations of STEP 2 of FIG. 19 above, in the case that there are more than one candidate cells in which the event (s) are evaluated as being met for CLTM, the following priority order may be applied to select the candidate cell to perform the cell switch:

[0333] 1: CLTM cell switch to the candidate cell in the same DU of the serving cell.

[0334] 2: CLTM cell switch to the candidate cell in the same CU of the serving cell.

[0335] 3: CLTM cell switch to the candidate cell in the inter-CU of the serving cell.

[0336] In some example implementations, the leaving indication to the serving cell above may include at least one of the following information:

[0337] 1: Candidate cell ID to indicate one or more selected candidate cells for which the cell switch is performed.

[0338] 2: CU Identifier to indicate the CU the candidate cell belongs to for UE to perform the CLTM Cell Switch.

[0339] 3: DL / Joint / UL TCI state ID to indicate the TCI state that is selected by UE for UL / DL transmission on target cell after Cell switch.

[0340] In some example implementations, the leaving indication to the serving cell may be at least one of the following formats:

[0341] 1: Uplink control indication (e.g., PUCCH signaling)

[0342] 2: UL MAC CE (e.g., CLTM Detaching Indication MAC CE) . In one implementation, if the CLTM Cell switch is triggered and there is no available PUSCH resources that can be used for sending a CLTM Detaching Indication MAC CE, then an SR may be triggered. In some example implementations, an LTM Cell switch MAC CE may be received by UE if the CLTM Cell Switch is triggered and the CLTM detaching Indication MAC CE have not been transmitted, then the UE may cancel the CLTM Cell Switch and perform the LTM Cell switch. In some example implementations, the UE may execute the CLTM Cell Switch as soon as the PUSCH including the CLTM Detaching Indication MAC CE is transmitted. In yet some other example implementations, the UE may not execute the CLTM Cell Switch until the confirmation and / or ACK from NW is received.

[0343] In some example implementations, STEP 3 of FIG. 19 above can be absent for the  whole procedure. When present, the Confirmation and / or ACK mechanism may be used to ensure that the NW receives the CLTM Detaching Indication MAC CE. In some implementations, the confirmation can provide NW’s suggestion to the UE on the candidate cell that the Cell switch is performed for if more than one candidate cell is provided in the CLTM Detaching Indication MAC CE. In some example implementations, the ACK to the UE may include a UL grant for a new transmission with a HARQ process ID the same as the UL transmission of the CLTM Detaching Indication MAC CE. In some example implementations, the confirmation may be implemented as a DL MAC CE (e.g., a CLTM Detaching Confirmation MAC CE or LTM Cell switch MAC CE) that is received by UE from PDSCH reception, including at least one of the following information:

[0344] 1: Candidate Cell Recommendation indication to indicate the candidate cell that is recommended for the cell switch.

[0345] 2: CU Indication to indicate the CU corresponding to the recommended candidate cell.

[0346] 3: DL / UL / Joint TCI state indication.

[0347] 4: CFRA Resources including SSB / CSI-RS Id, preamble Id, RO Mask Id.

[0348] 5: TA value.

[0349] In some example implementations, if the candidate cell indicated by CLTM Detaching Confirmation MAC CE is one of the selected candidate cells indicated in the CLTM Detaching Indication MAC CE, then the CLTM Cell Switch is performed. Otherwise, the LTM Cell switch is performed on the indicated candidate cell in the DL MAC CE. In some other example implementations, as long as the CLTM Detaching Confirmation MAC CE is received, then the LTM Cell Switch is performed.

[0350] In some example implementations of STEP 4 of FIG. 19 above, the Layer 2 and / or Layer 3 operations for the CLTM may be similar to LTM Cell Switch. In some example implementations, for the CLTM, in addition to the operations in LTM Cell switch, the MAC reset for CLTM Cell Switch may following at least one of the following rules:

[0351] ● Consider the TAT for the TA value stored in UE variables corresponding to the  CLTM candidate cells as not expired.

[0352] ● Consider the TAT of TAG corresponding to the candidate cell as not expired.

[0353] ● Consider only the TAT corresponding to the selected candidate cell for CLTM Cell switch as not expired.

[0354] In some example implementations of STEP 5a and STEP 5b of FIG. 19 above, for RACH based CLTM, the UE may perform the RACH based CLTM to the target cell if at least one of the following conditions are met:

[0355] ● No valid TA to the target cell has been stored at UE side.

[0356] ● No valid TA to the target cell has not been obtained by UE.

[0357] ● No Configured grant (CG) configuration for CLTM has been configured for the target cell.

[0358] ● An indication is configured in the RRC configuration of the target cell indicating that the CG based CLTM is not allowed.

[0359] For CG based CLTM, in some example implementations different from regular LTM, no indicated TCI states may be provided from the NW, then CG occasion selection for CLTM based on the UE measurement may be supported. For example, in the configured grant configuration used for CLTM Cell switch for a CLTM candidate cell, at least one of the following configurations may be needed:

[0360] ● Association between reference signaling (e.g., SSB ID  / CSI-RS ID) and CG PUSCH occasion.

[0361] ● SSB-MeasThreshold and / or CSI-MeasThreshold representing a Reference Signal Receive Power (RSRP) threshold for CG PUSCH occasion selection.

[0362] ● cLTM-RetransmissionTimer to indicate the length of retransmission timer for the first UL transmission. For example, the retransmission may only be performed by the expiry of the timer.

[0363] In some example implementations of the initial transmission, the UE may select the CG PUSCH occasion based on the L1-RSRP of the reference for initial UL transmission of the PDCCH message. For example, the SSB / CSI-RS resource pool for SSB / CSI-RS selection may be the TCI states that are activated by the Candidate Cell Activation / Deactivation MAC CE. If there are no SSB / CSI-RS from the activated TCI states that are above the preconfigured RSRP threshold or there are no TCI state being activated for the selected CLTM candidate cell, then the UE may perform a measurement on all the CSI-RS or SSBs having an association with CG PUSCH occasion.

[0364] In some example implementations, if there is no SSB / CSI-RS that can be selected for the initial transmission, the CG based CLTM may fall back to the RACH based CLTM. For an example of the retransmission of the first UL transmission, the UE may retransmit the first UL transmission with a configured grant if the cltm-RetransmissionTimer is expired and / or the ConfiguredGrantTimer is still running:

[0365] ● In some example implementations, the RACH based CLTM may be initiated for CLTM when the ConfigureGrantTimer is expired.

[0366] ● In some example implementations, the HARQ process ID for the retransmission may be the same as the one for the initial transmission.

[0367] ● In some example implementations, UE may be allowed to reselect the reference signal (e.g., SSB / CSI-RS) for the retransmission. For example, the UE may be allowed to reselect the reference signal that associates a PUSCH occasion having a different HARQ process ID with the initial transmission. In such implementations, the MAC entity of the UE may place the MAC PDU in the HARQ buffer of a HARQ process ID used for the initial transmission into a multiplex and assembled entity to generate a new MAC PDU for the HARQ process ID of the retransmission. For another example, the UE may not be allowed to reselect the reference signal that associates a PUSCH occasion having a different HARQ process ID with the initial transmission. In such implementations, only one HARQ process ID may be allocated to the CLTM configured grant, and then, in one association period of the configured grant, only one HARQ process ID may be associated with all the CG  PUSCH occasion, and the UE may freely select the suitable reference signal without any concern of HARQ process ID that the CG PUSCH occasion is associated with.

[0368] In some example implementations of STEP 6 of FIG. 19 above, the normal LTM termination procedure can be applied to the CLTM.

[0369] The description and accompanying drawings above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.

[0370] Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment / implementation” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment / implementation” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.

[0371] In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and” , “or” , or “and / or, ” as used herein may include a variety of meanings that may depend at least in part on the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly,  terms, such as “a, ” “an, ” or “the, ” may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

[0372] Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are included in any single implementation thereof. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same embodiment.

[0373] Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One of ordinary skill in the relevant art will recognize, in light of the description herein, that the present solution can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present solution.

Claims

1.A method performed by a user equipment (UE) in a wireless communication system, comprising:receiving, from a serving cell for the UE, a Layer-1 / Layer-2 Triggered Mobility (LTM) configuration for one or more candidate cells for an LTM cell switch or a conditional LTM (CLTM) cell switch, the one or more candidate cells comprising at least one inter-CU (Central Unit) candidate cell from the serving cell;performing an early downlink (DL) synchronization and an early uplink (UL) synchronization with the one or more candidate cells; andexecuting the LTM cell switch or the CLTM cell switch from the serving cell to a target cell among the one or more candidate cells according to the LTM configuration, the early DL synchronization and the early UL synchronization.2.The method of claim 1, wherein the at least one of the one or more candidate cells comprises multiple transmit-receive points (mTRPs) associated with two or more distinct time advances (TAs) for uplink communications with the UE.3.The method of claim 2, wherein the early DL synchronization comprises: receiving a transmission control indicator (TCI) state activation / deactivation media access control (MAC) control element (MAC CE) from the serving cell, the TCI state activation / deactivation MAC CE indicating a set of TCI states for activation in the at least one of the one or more candidate cells and indicating a corresponding control resource set pool (CORESET POOL) identifier (CORESET POOL ID) .4.The method of claim 2, wherein the early DL synchronization comprises: receiving a TCI state activation / deactivation MAC CE from the at least one of the one or more candidate cells, the TCI state activation / deactivation MAC CE indicating a plurality of codepoints and corresponding sets of joint mode or separate mode TCI states for activation in the at least one of the one or more candidate cells.5.The method of claim 1, wherein UE-based TA measurements for the early UL synchronization are disallowed with respect to the at least one inter-CU candidate cell.6.The method of claim 2, wherein UE-based TA measurements for the early UL synchronization are allowed for the at least one of the one or more candidate cells associated with the two or more distinct TAs, and a correspondence relationship between reference signals to be measured and the two or more distinct TAs are predefined, or specified in a configurable mapping relationship from network side, or determined by the UE.7.The method of claim 1, wherein the UE is configured to perform the CLTM cell switch, and wherein the method further comprises performing a preparation and reporting procedure for a transmission status with respect to the serving cell upon performing the CLTM cell switch.8.The method of claim 7, wherein the transmission status comprises identifying a first unreceived un-acknowledgement mode (UM) data unit by the UE from the serving cell.9.The method of claim 8, wherein the preparation procedure for the transmission status comprises:storing a counter or sequence number of the first unreceived UM data unit upon a successful termination of the CLTM cell switch; andgenerating a protocol data unit including the stored counter or sequence number.10.The method of claim 9, wherein the reporting procedure for the transmission status comprises sending the protocol data unit to the target cell for the target cell to determine which data units of earlier transfer data from the serving cell to the target cell have already been received by the UE prior to the CLTM cell switch and can be discarded from transmission at the target cell.11.The method of claim 1, wherein the UE is configured to perform both the LTM cell switch and the CLTM cell switch, and wherein the early DL synchronization comprises:receiving, from the serving cell, TCI state activation / deactivation MAC CEs indicating sets of TCI states to activate for the one or more candidate cells; andselecting only from the sets of TCI states when determining and performing the CLTM cell switch.12.The method of claim 1, wherein the UE is configured to perform both the LTM cell switch and the CLTM cell switch, and wherein the early DL synchronization comprises:performing L1 measurements on the one or more candidate cells;determining TCI states to be activated for the one or more candidate cells according to the L1 measurements; andinforming the one or more candidate cells of the TCI states to be activated using UL signaling.13.The method of claim 12, wherein the UL signaling comprises one or more UL MAC CEs.14.The method of claim 13, wherein each of the one or more UL MAC CEs comprises at least one of:indication of at least one UL / DL / Joint TCI State to be activated; orcode point of a Downlink Control Information (DCI) for a present UL / DL / Joint TCI state.15.The method of claim 1, wherein the UE is configured to perform the CLTM cell switch, and wherein the early UL synchronization comprises triggering a Physical Downlink Control Channel (PDCCH) ordered early RACH procedure, the PDCCH ordered early RACH procedure including receiving random access responses (RARs) from the serving cell in order to obtain TAs associated with the one or more candidate cells.16.The method of claim 1, wherein the UE is configured to perform the CLTM cell switch, and wherein the early UL synchronization comprises:triggering a Physical Downlink Control Channel (PDCCH) ordered early RACH procedure, the PDCCH ordered early RACH procedure being without RARs; andreceiving DL MAC CEs from the serving cell containing TAs associated with the one or more candidate cells.17.The method of claim 1, wherein the UE is configured to perform the CLTM cell switch, and wherein the early UL synchronization comprises:initiating an early RACH procedure with RAR presence; andreceiving RARs from the serving cell or the one or more candidate cells to extract TAs associated with the one or more candidate cells.18.A method performed by a wireless access network node in a wireless communication system, comprising:transmitting to a UE, via a serving cell of the wireless access network node for the UE, a Layer-1 / Layer-2 Triggered Mobility (LTM) configuration for one or more candidate cells for an LTM cell switch or a conditional LTM (CLTM) cell switch, the one or more candidate cells comprising at least one inter-CU (Central Unit) candidate cell from the serving cell;assisting with an early downlink (DL) synchronization and an early uplink (UL) synchronization between the UE and the one or more candidate cells; andassisting the LTM cell switch or the CLTM cell switch of the UE from the serving cell to a target cell among the one or more candidate cells according to the LTM configuration, the early DL synchronization and the early UL synchronization.19.The method of claim 18, wherein the at least one of the one or more candidate cells comprises multiple transmit-receive points (mTRPs) associated with two or more distinct time advances (TAs) for uplink communications with the UE.20.The method of claim 19, wherein the early DL synchronization comprises: transmitting a transmission control indicator (TCI) state activation / deactivation media access control (MAC) control element (MAC CE) to the UE, the TCI state activation / deactivation MAC CE indicating a set of TCI states for activation in the at least one of the one or more candidate cells and indicating a corresponding control resource set pool (CORESET POOL) identifier (CORESET POOL ID) .21.The method of claim 19, wherein the early DL synchronization comprises: transmitting a TCI state activation / deactivation MAC CE to the UE, the TCI state activation / deactivation MAC CE indicating a plurality of codepoints and corresponding sets of joint mode or separate node TCI states for activation in the at least one of the one or more candidate cells.22.The method of claim 18, wherein UE-based TA measurements for the early UL synchronization are disallowed with respect to the at least one inter-CU candidate cell.23.The method of claim 19, wherein UE-based TA measurements for the early UL synchronization are allowed for the at least one of the one or more candidate cells associated with the two or more distinct TAs, and a correspondence relationship between reference signals to be measured and the two or more distinct TAs are predefined, or specified in a configurable mapping relationship from network side, or determined by the UE.24.The method of claim 18, wherein the UE is configured to perform the CLTM cell switch, and wherein the method further comprises performing a preparation and reporting procedure for a transmission status with respect to the serving cell upon performing the CLTM cell switch.25.The method of claim 18, wherein the UE is configured to perform both the LTM cell switch and the CLTM cell switch, and wherein the early DL synchronization comprises:transmitting to the UE TCI state activation / deactivation MAC CEs indicating sets of TCI states to activate for the one or more candidate cells so that the UE only selects from the sets of TCI states when determining and performing the CLTM cell switch.26.The method of claim 18, wherein the UE is configured to perform the CLTM cell switch, and wherein the early UL synchronization comprises transmitting to the UE random access responses (RARs) TAs associated with the one or more candidate cells after the UE triggering a Physical Downlink Control Channel (PDCCH) ordered early RACH procedure.27.The method of claim 18, wherein the UE is configured to perform the CLTM cell switch, and wherein the early UL synchronization comprises:Transmitting, to the UE, DL MAC CEs containing TAs associated with the one or more candidate cells after the UE triggers a Physical Downlink Control Channel (PDCCH) ordered early RACH procedure without RARs.28.The method of claim 18, wherein the UE is configured to perform the CLTM cell switch, and wherein the early UL synchronization comprises:transmitting, to the UE, RARs for the UE to extract TAs associated with the one or more candidate cells after the UE initiates an early RACH procedure with RAR presence.29.A method performed by a wireless access network node in a wireless communication system, comprising:providing information of one or more candidate cells of the wireless access network node to a serving cell of a UE for the serving cell to generate a Layer-1 / Layer-2 Triggered Mobility (LTM) configuration for the one or more candidate cells for an LTM cell switch or a conditional LTM (CLTM) cell switch, the one or more candidate cells comprising at least one inter-CU (Central Unit) candidate cell from the serving cell;assisting with an early downlink (DL) synchronization and an early uplink (UL) synchronization with the one or more candidate cells; andexecuting with the UE the LTM cell switch or the CLTM cell switch of the UE from the serving cell to a target cell among the one or more candidate cells according to the LTM configuration, the early DL synchronization and the early UL synchronization.30.The method of claim 29, wherein the at least one of the one or more candidate cells comprises multiple transmit-receive points (mTRPs) associated with two or more distinct time advances (TAs) for uplink communications with the UE.31.The method of claim 29, wherein UE-based TA measurements for the early UL synchronization are disallowed with respect to the at least one inter-CU candidate cell.32.The method of claim 30, wherein UE-based TA measurements for the early UL synchronization are allowed for the at least one of the one or more candidate cells associated with  the two or more distinct TAs, and a correspondence relationship between reference signals to be measured and the two or more distinct TAs are predefined, or specified in a configurable mapping relationship from network side, or determined by the UE.33.The method of claim 29, wherein the UE is configured to perform the CLTM cell switch, and wherein the method further comprises receiving, from the UE, a protocol data unit indicating which data units of earlier transfer data from the serving cell to the target cell have already been received by the UE prior to the CLTM cell switch and can be discarded from transmission at the target cell.34.The method of claim 33, wherein the protocol data unit identifies a first unreceived un-acknowledgement mode (UM) data unit by the UE from the serving cell.35.The method of claim 29, wherein the UE is configured to perform both the LTM cell switch and the CLTM cell switch, and wherein the early DL synchronization comprises:receiving an UL signaling from the UE indicating TCI states to be activated, the TCI states identified by the UE via L1 measurements of the one or more candidate cells.36.The method of claim 35, wherein the UL signaling comprises one or more UL MAC CEs.37.The method of claim 36, wherein each of the one or more UL MAC CEs comprises at least one of:indication of at least one UL / DL / Joint TCI State to be activated; orcode point of a Downlink Control Information (DCI) for a present UL / DL / Joint TCI state.38.The method of claim 29, wherein the UE is configured to perform the CLTM cell switch, and wherein the early UL synchronization comprises:transmitting RARs to the UE for the UE to extract TAs associated with the one or more candidate cells after the UE initiating an early RACH procedure with RAR presence.39.The UE or the wireless access network node of any one of claims 1 to 38 comprising at least one processor and a memory, wherein the at least one processor is configured to read code from the memory to implement the method recited in any one of claims 1 to 38.40.A computer program product comprising a computer-readable code stored thereupon, the computer-readable code, when executed by at least one processor of the UE or wireless access network node of any one of claims 1 to 38, causes the at least one processor to implement the method recited in any one of claims 1 to 38.

Images