Method for cell handover and timing advance acquisition for layer 1 / layer 2 triggering in wireless communication system

Abstract

The present disclosure relates generally to wireless communication networks, and particularly layer 1 / layer 2 triggered mobility or cell handover in cellular wireless networks. Specifically, various embodiments are disclosed to facilitate obtaining a time advance (TA) of a target cell or candidate cell prior to an actual cell handover in order to achieve a more efficient and faster cell handover. The actual cell handover may be triggered in layer 1 or layer 2 of the wireless network. By acquiring the TA in advance, cell handover based on mobility (LTM) triggered by layer 1 / layer 2 can be performed without a random access procedure. The following various embodiments further provide for detailed example processes for configuration to enable early TA acquisition, example processes for acquiring TA, and examples of LTM handover based on the acquired TA.

Description

Technical Field

[0001] The present disclosure relates generally to wireless communication networks, and in particular to layer 1 / layer 2 triggered mobility or cell handover in cellular wireless networks. Background Art

[0002] Mobility of a wireless terminal in a cellular wireless network involves switching from a source cell to a target cell. The source cell and the target cell may be provisioned by the same base station or may be provisioned by different base stations. Cell switching of a wireless terminal may be triggered in the lower layers of the wireless network. For example, such cell switching may be triggered in layer 1 or layer 2 of the wireless network. Uplink information from the wireless mobile terminal to the base station may be transmitted in conjunction with a timing advance (TA) in order to account for uplink transmission delays. Therefore, the process of obtaining the TA for uplink transmissions between the mobile terminal and the target cell during or before a cell handover constitutes an important part of wireless network operation. Summary of the Invention

[0003] The present disclosure relates generally to wireless communication networks, and in particular to layer 1 / layer 2 triggered mobility or cell handover in cellular wireless networks. Specifically, various embodiments are disclosed to facilitate acquiring a timing advance (TA) of a target cell or candidate cell before the actual cell handover, thereby achieving more efficient and faster cell handover. The actual cell handover can be triggered in layer 1 or layer 2 of the wireless network. With the TA acquired in advance, a cell handover based on layer 1 / layer 2 triggered mobility (LTM) can be performed without a random access procedure. The various embodiments below further provide detailed example processes for implementing a configuration for early TA acquisition, example processes for acquiring a TA, and examples of LTM handover based on the acquired TA.

[0004] In one example embodiment, a method performed by a wireless terminal in communication with a current serving cell is disclosed. The method may include: receiving a timing advance (TA) configuration from the current serving cell to assist in acquiring a timing advance (TA) associated with a candidate cell; acquiring the TA based on the TA configuration; receiving a Layer 1 / Layer 2 Triggered Mobility (LTM) command instructing the wireless terminal to perform a cell handover to the candidate cell; and performing a cell handover without random access from the current serving cell to the candidate cell based on the LTM command.

[0005] In the above example embodiments, acquiring the TA according to the TA configuration may include performing an early random access procedure on the candidate cell, where the early random access procedure is designed for acquiring a timing advance rather than for uplink data transmission.

[0006] In any one or more of the above example embodiments, the early random access procedure is performed using a set of random access resources configured for early random access in a TA configuration. In any one or more of the above example embodiments, the TA configuration is communicated from the current serving cell to the wireless terminal in a radio resource control (RRC) configuration message.

[0007] In any one or more of the above exemplary embodiments, the set of random access resources is configured as cell-specific random access resources for non-exclusive use by an early random access procedure in a contention-based manner.

[0008] In any one or more of the above exemplary embodiments, the set of random access resources is configured as UE-specific random access resources dedicated to the wireless terminal for non-exclusive use by an early random access procedure in a contention-free manner.

[0009] In any one or more of the above-mentioned example embodiments, the early random access process includes sending a random access preamble code to the candidate cell; and the method also includes transmitting a control message to the candidate cell, which indicates to the candidate cell that the random access preamble code sent by the wireless terminal is used for early random access and TA acquisition, rather than uplink transmission.

[0010] In any one or more of the above exemplary embodiments, the set of random access resources is configured as UE-specific random access resources dedicated to the wireless terminal for exclusive use by the early random access procedure.

[0011] In any one or more of the above exemplary embodiments, the method further includes determining a random access type of the early random access procedure before performing the early random access procedure, the random access type being one of a contention-based random access type or a contention-free random access type.

[0012] In any one or more of the above exemplary embodiments, the method further includes determining that the early random access procedure is a contention-based random access type when the LTM command does not include identification information of the random access resource set.

[0013] In any one or more of the above exemplary embodiments, the method further includes determining that the early random access procedure is a contention-free random access type when the LTM command includes identification information of a UE-specific random access resource.

[0014] In any one or more of the above example embodiments, determining the random access type of the early random access procedure includes extracting an explicit type indicator in an RRC configuration associated with a set of random access resources configured for the early random access procedure.

[0015] In any one or more of the above exemplary embodiments, the current serving cell is preset by a first distributed unit base station, and the candidate cell is preset by a second distributed unit base station, which is different from the first distributed unit base station.

[0016] In any one or more of the above example embodiments, the TA configuration originates from the second distributed cell base station and is transmitted to the first distributed cell base station via the central cell base station before being transmitted by the first distributed cell base station and received by the wireless terminal.

[0017] In any one or more of the above exemplary embodiments, the method further includes performing a notification process on the current serving cell to indicate to the current serving cell that the wireless terminal will return to the current serving cell after acquiring the TA.

[0018] In any one or more of the above-mentioned example embodiments, the notification process includes triggering and sending a scheduling request, sending a sounding reference signal (SRS), or sending a medium access control (MAC) control element (MAC CE) on the current serving cell once the TA associated with the candidate cell is obtained.

[0019] In any one or more of the above exemplary embodiments, the method further includes sending a control message to the first distributed unit base station, the control message including the TA as acquired by the wireless terminal.

[0020] In any one or more of the foregoing example embodiments, the early random access procedure includes transmitting a random access preamble to a candidate cell and receiving a random access response from a first distributed cell base station associated with a current serving cell, the random access response being relayed by a central cell base station from a second distributed cell base station associated with the candidate cell.

[0021] In any one or more of the above-described example embodiments, the early random access procedure includes sending a random access preamble to a candidate cell and receiving a random access response message including a TA from the candidate cell.

[0022] In any one or more of the above example embodiments, the early random access procedure includes sending a random access preamble to a candidate cell and receiving a random access response message including a TA associated with the candidate cell from the candidate cell or the current serving cell, followed by termination of the early random access procedure.

[0023] In any one or more of the above example embodiments, the current serving cell and the candidate cell are preset by the same distributed unit base station; and the early random access procedure includes sending a random access preamble to the candidate cell and receiving a random access response associated with the candidate cell from the same distributed unit base station.

[0024] In any one or more of the above-described example embodiments, the TA configuration indicates to the wireless terminal that the TA associated with the candidate cell will be approximated by a cell within the same timing advance group (TAG) as the candidate cell; and obtaining the TA according to the TA configuration includes obtaining a known reference TA within the TAG as the TA associated with the candidate cell.

[0025] In any one or more of the above example embodiments, the method further comprises performing at least one layer 2 reset operation upon receiving the LTM command.

[0026] In some other embodiments, an electronic device including a processor and a memory is disclosed. The processor may be configured to read computer code from the memory to implement any one of the above methods.

[0027] In yet other embodiments, a computer program product is disclosed, which includes a non-transitory computer-readable program medium having computer code stored thereon. When executed by a processor, the computer code may cause the processor to implement any one of the above methods.

[0028] Other aspects and alternatives to the above-described embodiments and their implementations are described in more detail in the following drawings, description, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

[0033] Figure 5 An example of a random access procedure jointly performed by a mobile station and a radio access network node is shown.

[0034] Figure 6 An example flow chart of the early RACH preparation phase for obtaining TA in advance for inter-DU (Distributed Unit) or intra-DU Layer 1 / Layer 2 Triggered Mobility (LTM) is shown.

[0035] Figure 7 An example flow chart of early RACH triggering is shown.

[0036] Figure 8 An example general flow diagram of an early RACH execution for acquiring a TA is shown.

[0037] Figure 9 An example procedure for LTM cell handover is shown. DETAILED DESCRIPTION

[0038] Examples of the techniques and implementations and / or embodiments described in this disclosure can be used to facilitate the transmission and reception of artificial intelligence (AI) network management models between various wireless network devices or nodes via at least one air interface. In this disclosure, the term "over-the-air interface" is used interchangeably with "air interface" or "radio interface". The term "exemplary" is used to mean "an example of..." and, unless otherwise specified, does not imply an ideal or preferred example, implementation, or embodiment. The section headings used in this disclosure are intended to facilitate understanding of the disclosed implementations and are not intended to limit the techniques disclosed in the sections to only the corresponding sections. The disclosed implementations may also be embodied in a variety of different forms, and therefore, the scope of the present disclosure or claimed subject matter is intended to be interpreted as not being limited to any embodiment set forth below. Various implementations may be embodied as methods, devices, components, systems, or non-transitory computer-readable media. Therefore, the embodiments of the present disclosure may, for example, take the form of hardware, software, firmware, or any combination thereof.

[0039] The present disclosure relates generally to wireless communication networks, and in particular to layer 1 / layer 2 triggered mobility or cell handover in cellular wireless networks. Specifically, various embodiments are disclosed to facilitate acquiring a timing advance (TA) of a target cell or candidate cell before the actual cell handover, so as to achieve more efficient and faster cell handover. The actual cell handover can be triggered in layer 1 or layer 2 of the wireless network. By acquiring the TA in advance, a cell handover based on layer 1 / layer 2 triggered mobility (LTM) can be performed without a random access procedure. The various embodiments below further provide detailed example processes for implementing a configuration for early TA acquisition, example processes for acquiring the TA, and examples of LTM handover based on the acquired TA.

[0040] Wireless Network Overview

[0041] Figure 1An example wireless communication network, shown as 100, may include wireless terminal devices or user equipment (UEs) 110, 111, and 112, an operator network 102, various service applications 140, and other data networks 150. The wireless terminal devices or UEs may alternatively be referred to as wireless terminals. Operator network 102 may include, for example, access network nodes 120 and 121 and a core network 130. Operator network 110 may be configured to transmit voice, data, and other information (collectively, data traffic) within UEs 110, 111, and 112, between UEs and service applications 140, or between UEs and other data networks 150. Access network nodes 120 and 121 may be configured as various wireless access network nodes (WANNs, alternatively referred to as wireless base stations) to interact with UEs on one side of a communication session and core network 130 on the other side. The term "access network" may be used more broadly to refer to the combination of wireless terminal devices 110, 111, and 112 and access network nodes 120 and 121. The wireless access network may alternatively be referred to as a radio access network (RAN). The core network 130 may include various network nodes configured to control communication sessions and perform network access management and traffic routing. Service applications 140 may be hosted by various application servers deployed outside the core network 130 but connected to the core network 130. Similarly, other data networks 150 may also be connected to the core network 130.

[0042] exist Figure 1 In the example wireless communication network 100 of FIG. 1 , UEs may communicate with each other via a radio access network. For example, UEs 110 and 112 may be connected to the same access network node 120 and communicate via the access network node 120. The UEs may communicate with each other via both the access network and the core network. For example, UE 110 may be connected to access network node 120, while UE 111 may be connected to access network node 121, and thus, UE 110 and UE 111 may communicate with each other via access network nodes 120 and 121 and core network 130. The UEs may also communicate with service applications 140 and data network 150 via core network 130. In addition, the UEs may communicate directly with each other via sidelink communications, as shown by 113.

[0043] Figure 2Also shown is an example system diagram of a wireless access network 120 including a WANN 202 serving UEs 110 and 112 via an air interface 204. The wireless transmission resources of the air interface 204 include a combination of frequency, time and / or space resources. Each of the UEs 110 and 112 can be a mobile or fixed terminal device equipped with a mobile access unit (such as a SIM / USIM module) for accessing the wireless communication network 100. The UEs 110 and 112 can each be implemented as a terminal device, including but not limited to a mobile phone, a smart phone, a tablet computer, a laptop computer, an in-vehicle communication equipment, a roadside communication equipment, a sensor device, a smart appliance (such as a TV, a refrigerator, and an oven), or other devices capable of wireless communication over a network. Figure 2 As shown, each UE, such as UE 112, may include a transceiver circuit 206 coupled to one or more antennas 208 to enable wireless communication with WANN 120 or with another UE, such as UE 110. Transceiver circuit 206 may also be coupled to a processor 210, which may also be coupled to a memory 212 or other storage device. Memory 212 may be transient or non-transitory and may store therein computer instructions or code that, when read and executed by processor 210, cause processor 210 to implement the various methods described herein.

[0044] Similarly, WANN 120 may include a wireless base station or other wireless network access point capable of wirelessly communicating with one or more UEs and communicating with core network 130 via air interface 204. For example, WANN 120 may be implemented, without limitation, as a 2G base station, a 3G nodeB, an LTE eNB, a 4G LTE base station, a 5G NR base station for a 5G gNB, a 5G central unit base station, or a 5G distributed unit base station. Each of these WANN types may be configured to perform a corresponding set of wireless network functions. WANN 202 may include transceiver circuitry 214 coupled to one or more antennas 216, which may include various forms of antenna towers 218, to enable wireless communication with UEs 110 and 112. Transceiver circuitry 214 may be coupled to one or more processors 220, which may also be coupled to a memory 222 or other storage device. The memory 222 may be transient 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.

[0045] Such as Figure 2Data packets in the example wireless access network described in the specification may be transmitted as protocol data units (PDUs). The data included therein may be packaged into PDUs at various network layers, which are wrapped with nested and / or hierarchical protocol headers. Once a connection (e.g., a radio link control (RRC) connection) is established between the transmitting end and the receiving end, the PDUs may be communicated between a transmitting device or transmitting end (the two terms are used interchangeably) and a receiving device or receiving end (the two terms are also used interchangeably). Either the transmitting device or the receiving device may be a wireless terminal device (such as a wireless terminal device). Figure 2 devices 110 and 120), or wireless access network nodes such as Figure 2 Each device may be a transmitting device and a receiving device for bidirectional communication.

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

[0047] Returning to the Wireless Radio Access Network (RAN), Figure 3 An example RAN 340 is shown in communication with a core network 310 and wireless terminals UE1 to UE7. RAN 340 may include one or more wireless base stations or WANs 320 and 321 of various types, including, but not limited to, gNBs, eNodeBs, NodeBs, or other types of base stations. RAN 340 may be backhauled to core network 310. WANN 320 may also include, for example, multiple individual access network nodes in the form of a central unit (CU) 322 and one or more distributed units (DUs) 324 and 326. CU 322 connects to DU1 324 and DU2 326 via various interfaces, such as an F1 interface. The F1 interface may also include, for example, 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). Although the various embodiments described below are provided in the context of a 5G cellular wireless network, the basic principles described herein are applicable to other types of radio access networks, including but not limited to other generations of cellular networks, as well as Wi-Fi, Bluetooth, ZigBee, and WiMax networks.

[0048] The UE may be connected to the network via the WANN 320 over the air interface. The UE may be served by at least one cell. Each cell is associated with a coverage area. These cells may alternatively be referred to as serving cells. The coverage areas between cells may partially overlap. Each UE may be actively communicating with at least one cell and may potentially be connected or connectable to more than one cell. Figure 1 In the example shown in FIG, UE1, UE2, and UE3 can be served by cell1 330 of DU1, while UE4 and UE5 can be served by cell2 332 of DU1, and UE6 and UE7 can be served by cell3 associated with DU2. In some embodiments, a UE can be served by two or more cells simultaneously. Each UE can be mobile, and the signal strength and quality from each cell at the UE can depend on the UE's location and mobility.

[0049] In some example embodiments, Figure 3 The cells shown in the figure may alternatively be referred to as serving cells. Serving cells may be grouped into serving cell groups (CGs). A serving cell group may be a main CG (MCG) or a secondary CG (SCG). In each type of cell group, there may be one main cell and one or more secondary cells. For example, the main cell in an MSG may be referred to as a PCell, and the main cell in an SCG may be referred to as a PScell. A secondary cell in either an MCG or an SCG may be referred to as an SCell. The main cell including the PCell and the PScell ​​may be collectively referred to as a spCell (special cell). All of these cells may be referred to as serving cells or cells. Unless otherwise specifically distinguished, the terms "cell" and "serving cell" may be used interchangeably in a general manner. The term "serving cell" may refer to a cell that is serving, will serve, or can serve a UE. In other words, a "serving cell" may not currently be serving a UE. Although the various embodiments described below may sometimes relate to one of the above-mentioned serving cell types, the basic principles apply to all types of serving cells in these two serving cell groups.

[0050] Figure 4 It is further shown that Figures 1 to 3 FIG. 4 is a simplified diagram of the various network layers involved in transmitting a user plane PDU from a transmitting device 402 to a receiving device 404 in an example wireless access network. Figure 4 It is not intended to include all basic equipment components or network layers used to handle PDU transmission. Figure 4 It is shown that data packetized by the upper network layer 420 at the transmitting device 402 can be transmitted to the corresponding upper layer 430 (such as the radio resource control or RRC layer) at the receiving device 304 via the Packet Data Convergence Protocol layer (PDCP layer, Figure 4The PDUs are embodied as follows: a physical (PHY) layer and radio interface (shown as 406) of the transmitting and receiving devices, and a medium 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 PDUs.

[0051] exist Figure 4 The upper layer 420 may be referred to as Layer 3 or L3, while layers such as the RLC layer and / or the MAC layer and / or the PDCP layer ( Figure 4 The intermediate layers (not shown) 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 radio interface related layers. In some cases, the term "lower layer" may be used to refer to the set of L1 and L2, while the term "higher layer" may be used to refer to Layer 3. In some cases, the term "lower layer" may be used to refer to layers in L1, L2, and L3 that are lower than the current reference layer. Control signaling may be initiated and triggered within each of L1 to L3 and the various network layers therein. These signaling messages may be encapsulated and concatenated into lower layer packets and transmitted via allocated control or data air radio resources and interfaces. The term "layer" generally includes its various corresponding entities. For example, the MAC layer includes corresponding MAC entities that can be created. Layer 1, for example, includes a PHY entity. As another example, Layer 2 includes a MAC layer / entity, an RLC layer / entity, a Service Data Adaptation Protocol (SDAP) layer, and / or a PDCP layer / entity.

[0052] Random access process

[0053] Return to Figure 1UEs can communicate with WANNs 120 and 121 using wireless network communication resources allocated by the WANN. Such wireless network communication resources may include, but are not limited to, radio frequency carrier frequencies and time slots. Unlike conventional circuit-switched communication systems based on pre-assigned and dedicated communication channels, wireless access networks can be more efficiently implemented, at least in part, using random access. Specifically, a user mobile station can request access to network communication resources at random times and on demand. When a user mobile station issues a random access request, network resources and synchronization information may be available and allocated by the WANN. In some embodiments, a mobile station's request for random access may be transmitted via one or more random access communication resources or random access channels (RACHs). Information regarding RACH allocation and assignment may be provided from the WANN to the UE during the initial communication establishment process. For example, the random access communication resource configuration may be included in a random access channel configuration message (e.g., an RRC message) generated by the WANN. The RACH configuration message may be broadcast by the WANN to the user mobile station. Based on the RACH configuration message, the user mobile station may select a RACH from among all available RACHs for transmitting the random access request to the WANN. The term "channel" is used herein to broadly refer to network transmission resources, including but not limited to any combination of transmission carrier frequencies and time slots.

[0054] Regarding the allocation of random channel resources between UEs, random access can be contention-based or contention-free, respectively referred to as CBRA (Contention-Based Random Access) or CFRA (Contention-Free Random Access). In CFRA, random access communication resources such as RACH can be dedicated to a UE, while in CBRA, random access communication resources can be shared between UEs and therefore contention may occur.

[0055] Figure 5 An example implementation of a CBRA request and allocation process 500 is shown. The contention-based RACH process begins at step 1 (502) where the WANN 501 performs optimization on the RACH configuration to obtain an optimized RACH configuration. Optimization of the RACH configuration may involve designing a RACH preamble based on various network operating parameters available at the WANN to optimize RACH efficiency and reduce potential contention between user mobile stations. Once the optimized RACH configuration is determined, the WANN may broadcast the optimized RACH configuration via, for example, a predetermined control channel. For example, in step 2 (504), the optimized RACH configuration may be broadcast as part of a synchronization signal and a physical broadcast channel block (SSB).

[0056] continue Figure 5 And at step 3 (512), the user mobile station 503 receives the optimized RACH configuration broadcast by the MANN 501. The user mobile station then selects a random access preamble from a plurality of random access preambles indicated as being available in the optimized RACH configuration and communicates the selection to the MANN, as shown in 513. At step 4 (506), the MANN receives the preamble selection from the user mobile station and provides a response to the mobile station. The response may include network resources allocated for the mobile station for transmission to the MANN and timing advance (TA) information (described in further detail below). The mobile station receives the response at step 5 (514) and extracts, for example, the allocated network resources and TA from the response. The mobile station then prepares its transmitter to schedule transmission and transmits the information and TA to the MANN using, for example, the allocated network resources, as shown in 515. If there is no competition for network resources from other user mobile stations, the random access of the mobile station is determined to be established. Otherwise, the WANN continues to resolve the contention in step 6 (508) before the random access of the user mobile station 503 is allowed to be established or is not allowed to make the allocated network resources available to some other competing user mobile stations.

[0057] Figure 5 The CBRA implementation can be referred to as a four-step process. These four steps refer to the transmission of messages 513 (preamble from the mobile station to the WANN), 506 (random access response (RAR) from the WANN to the mobile station), 515 (scheduled data transmission from the mobile station to the WANN), and 508 (for contention resolution). These four messages can be referred to as Msg 1, Msg 2, Msg 3, and Msg 4, respectively.

[0058] In CFRA, when the UE uses a dedicated random access preamble, no contention resolution will be required.

[0059] In some other exemplary alternative embodiments, a 2-step RACH procedure is used instead of a 4-step RACH procedure. In the exemplary 2-step RACH procedure, Msg 1 and Msg 3 described above can be combined to include both the RACH preamble and data, referred to as MSGA, and Msg 2 and Msg 4 described above can be combined into one response message, referred to as MSGB. If there is contention and the transmission fails, the UE retries the procedure.

[0060] Timing Advance (TA)

[0061] For communications in the air interface from each UE to the base station, the timing of uplink transmissions can be controlled based on a timing advance (TA). The timing advance of each UE relative to the base station helps ensure that uplink transmissions from all UEs are synchronized when received by the base station. The TA of a particular UE communicating with a base station essentially depends on the transmission propagation delay, which is directly related to the path length from the UE to the base station (the aforementioned DU). The UE typically needs to acquire and maintain the TA associated with the base station with which it communicates in order to effectively control the timing of its uplink signal transmission using any allocated uplink transmission resources.

[0062] In a radio connection based on a random access procedure, the TA may initially be communicated from the base station to the UE during the random access procedure in a random access response (RAR) after the UE issues a random access request (e.g., as described above with respect to CBRA). Figure 5 The timing advance amount may also be communicated to the UE via a MAC control element (MAC CE) including a timing advance command (TAC).

[0063] Layer 1 / Layer 2 Triggered Mobility (LTM) and Advance Retrieval of Candidate Cell TAs

[0064] In some embodiments of UE mobility from one cell to another, a cell handover of the UE may be triggered in the aforementioned Layer 1 or Layer 2. This UE mobility may be referred to as Layer 1 / Layer 2 Triggered Mobility (LTM). The signaling of LTM may be performed using a RACH-based solution or a RACH-free solution. For RACH-based LTM, handover and access to a candidate cell may be requested and implemented via the aforementioned contention-based or contention-free random access procedure. In this case, the TA information desired for subsequent uplink transmission and communication may be obtained from the RAR in the random access procedure. However, for RACH-free LTM, where handover to a candidate cell and subsequent uplink communication do not involve a random access procedure, TA information must be obtained in advance to determine the timing of the uplink communication. Therefore, in some embodiments, whether RACH-free LTM or RACH-based LTM is used may depend on whether TA information is available at the UE regarding the candidate cell. The terms "candidate cell" and "target cell" may be used interchangeably in this disclosure.

[0065] In some example embodiments, in anticipation of or in preparation for RACH-free LTM, a PDCCH-ordered (Physical Downlink Control Channel-ordered) RACH procedure may be initiated for the purpose of obtaining the TA value of the candidate cell in advance, making it available for RACH-free LTM. Such a PDCCH-ordered RACH is essentially a random access procedure triggered by a PDCCH instruction or command (e.g., a DCI message). For example, cell-specific RACH resources may be allocated by the base station, and the UE currently connected to the source serving cell may be instructed in the PDCCH instruction to send a RACH request (e.g., a preamble) to the candidate cell and receive a RAR containing the TA associated with the candidate cell in response to the RACH request. Once the TA of the candidate cell is obtained, the UE will then switch back to the source cell, and the TA will be available for potential RACH-free LTM. The RACH of the PDCCH order may be CFRA (eg, where the preamble ID present in the PDCCH order is not 0b000000) or CBRA (eg, where the preamble ID present in the PDCCH order is 0b000000).

[0066] In some example embodiments, the RAR reception and preamble transmission in the RACH of the PDCCH command may be performed on different serving cells. For example, the UE may transmit a preamble to the candidate cell upon receiving the PDCCH command on the source cell, and may receive the RAR carrying the candidate cell TA on the source cell. This embodiment may operate when the source cell and the candidate cell belong to the same DU and are controlled / coordinated by the same DU. For inter-DU LTM, where the candidate cell and the source cell belong to different DUs, such a PDCCH-commanded RACH procedure for obtaining the candidate cell TA in advance and not involving inter-DU communication may be ineffective.

[0067] Various embodiments disclosed below describe example approaches in which the TA of a candidate cell is obtained in advance via an early RACH procedure to facilitate RACH-free LTM between or within a DU, either with or without a PDCCH-ordered RACH. The term "early RACH" is used to indicate that this RACH procedure for obtaining the TA precedes the actual LTM-based handover.

[0068] In addition, when performing LTM, user plane (UP) data transmission interruptions should be avoided / minimized as much as possible. Therefore, the details of L2 operation are crucial to the LTM process. The following various embodiments further provide example methods for performing LTM while reducing or minimizing UP data interruptions.

[0069] Early RACH preparation / configuration

[0070] In order to prepare for the early RACH procedure to obtain the TA of the candidate cell, RACH resources for the early RACH should be configured first. Figure 6 An example implementation is shown in FIG. Figure 6 UE 602 is shown communicating with a current serving cell 604 (or source serving cell) belonging to Dux and possibly receiving LTM from a candidate or candidate serving cell 606 belonging to DUy. For inter-DU LTM, DUx and DUy represent different DUs, while for intra-DU LTM, DUx and DUy represent the same DU. Both DUx and DUy are preset by CU 608. The term "serving cell" may be referred to alternatively in a similar manner to "cell."

[0071] Early RACH preparation and configuration may involve the following example steps.

[0072] In step 0, and for the inter-DU case, as shown in 610, the early RACH resource configuration in the candidate cell may be allocated by the candidate cell 606 having DUy and communicated to the current source cell 604 having DUx via the CU 608. The CU 608 may be relied upon as an intermediate network node for this early RACH configuration, since DUx and DUy do not communicate directly but may communicate via the CU 608. Therefore, step 0 for the inter-DU case may include the following sub-steps.

[0073] • Step 0.1: CU 608 may generate an early RACH resource request message 612 and transmit it to DUy to which the candidate cell 606 belongs.

[0074] Step 0.2: The DUy to which the candidate cell 606 belongs may generate an early RACH resource response and transmit it to the CU 608 .

[0075] • Step 0.3: The RRC configuration 616 used for early RACH to obtain the TA value of the candidate cell 606 is then forwarded to the DUx to which the source cell 604 belongs.

[0076] In step 0 and for the intra-DU scenario, as shown in 620, the early RACH resource configuration can be generated by the DU to which the candidate cell 606 and the current source cell 604 belong, without requiring any CU participation. In other words, since the candidate cell 606 and the source cell 604 share the same DU, the shared DU will directly generate the RRC configuration for the early RACH resources for the candidate cell.

[0077] In step 1, the RRC configuration generated for early RACH in step 0 may then be transmitted from the source cell 604 to the UE 602 by DUx for both inter-DU and intra-DU cases.

[0078] In some example embodiments, the PRACH resources (e.g., RACH timing and / or preamble) for the early RACH may be configured within a cell-specific RACH configuration, e.g., the RRC configuration for the early RACH may be specific to the candidate cell 606. In some example embodiments, the configured PRACH resources for the early RACH may be shared with the CBRA for LTM. In such embodiments, the resources for the early RACH may be configured, for example, within RACH-ConfigCommon. In such cases, various embodiments may be designed so that the candidate cell 606 distinguishes between an early RACH request and a RACH request for an LTM handover to the candidate cell, as described in further detail below.

[0079] In some other example embodiments, the PRACH resources (e.g., RACH timing and / or preamble) for the early RACH may be configured within a UE-specific or dedicated RACH configuration. In such embodiments, the PRACH resources for the early RACH may be configured, for example, within RACH-ConfigDedicated. In some example embodiments, the dedicated PRACH resources for the early RACH may be shared with the LTM based on CFRA. In this case, various embodiments may be designed so that the candidate cell 606 distinguishes between an early RACH request and a RACH request for the LTM using UE-specific RACH resources, as described in further detail below.

[0080] In some other example embodiments, RACH resources for early RACH in a candidate cell dedicated to a UE may be configured separately from RACH resources used by the UE to perform RACH in an LTM-based cell handover. For example, PRACH resources for early RACH may be separate from PRACH resources used for RACH procedures in an LTM cell handover. In one embodiment of this example, RACH opportunities configured for early RACH may be separate from RACH opportunities used for RACH in an LTM cell handover. In another embodiment of this example, RACH preamble resources for early RACH may be separate from RACH preamble resources used for RACH in an LTM cell handover.

[0081] In some example embodiments, for the inter-DU case, additional steps may precede the above step 0. Specifically, the source cell 604 associated with DUx may first transmit an early RACH resource request message to the CU 608 to trigger the CU 608 to transmit its early RACH resource request 612 to the candidate cell 606 associated with DUy.

[0082] Early RACH triggering

[0083] Once the early RACH resources in the candidate cell are configured, they can be used for the UE to perform an early RACH procedure with the candidate cell in order to obtain a TA in advance before any actual LTM-based cell handover. Figure 7 An example of triggering such an early RACH procedure is shown in flowchart 700. Flowchart 700 may include the following example steps.

[0084] In step 1 , the source serving cell 704 associated with DU x may transmit an early RACH command 710 to the UE 702 to initiate an early RACH on the candidate cell 706 to acquire the TA of the candidate cell 706 .

[0085] In some example embodiments, the early RACH command 710 may be transmitted as L1 signaling (e.g., a DCI image), which may include at least one of the following information:

[0086] • Candidate cell group ID, used to identify the candidate cell group associated with the candidate cell 706 whose TA value is to be obtained.

[0087] Candidate cell ID, used to identify the candidate cell 706 whose TA value is to be obtained.

[0088] • SSB or CSI-RS ID, used to indicate one or more SSBs or CSI-RSs to be selected for RACH resource selection when initiating early RACH, based on the mapping between these reference signals and RACH resources.

[0089] The Preamble ID field is used to indicate the preamble to be selected when initiating an Early RACH. When the value of this field is 0B000000, CBRA shall be applicable to the Early RACH procedure, in which the actual RACH preamble may be selected by the MAC entity.

[0090] • One or more RACH opportunity (RO) IDs or / and one or more physical RACH (PRACH) MASKs, used to indicate one or more RACH opportunities to be selected for transmitting the RACH preamble when initiating an early RACH procedure with a candidate cell.

[0091] · RACH resource pool indicator, used to indicate which RACH resource pool will be used to initiate the early RACH procedure with the candidate cell.

[0092] In some other embodiments, the early RACH command 710 may be implemented as L2 signaling (e.g., a MAC CE). For example, the MAC CE may be implemented as the same type of MAC CE used to trigger an actual LTM cell handover (e.g., a RACH-based LTM cell handover). In such embodiments, to distinguish the use of the early RACH for acquiring the TA from the use of the LTM RACH for the target cell or candidate cell, an indication field may be included in the MAC CE. For example, if the field is set to 1, it may mean that the MAC CE is used to trigger the early RACH to acquire the TA. Otherwise, if the field is set to 0, it may mean that the MAC CE is used to trigger the LTM-based cell handover. The MAC CE command for triggering the earlier RACH procedure may include at least one of the information items listed above for the L1 layer implementation of the early RACH command 710.

[0093] exist Figure 7 In step 2, the UE 702 may apply early RACH configuration (e.g., early RACH RRC configuration) according to the received early RACH command 710, as shown in 720. Such configuration may include determining RACH resources (RACH preamble, RACH timing, channel, etc.) and / or determining parameters related to the RACH process (maximum number of preamble transmissions, reference signal received power (RSRP) threshold for SSB or CSI-RS selection).

[0094] exist Figure 7 In step 3, the UE 702 may determine the RACH type (e.g., CFRA or CBRA) of the early RACH procedure according to the received early RACH command and / or the applied RRC configuration of the early RACH, and initiate the early RACH procedure according to the applied RRC configuration of the RACH and the received early RACH command, as shown in FIG. Figure 7 As shown in box 730.

[0095] In step 3( Figure 7In the above example implementation of 730), the early RACH procedure initiated by the UE may be of CFRA (contention-free RACH) or CBRA (contention-based RACH) type. For an early RACH procedure of the CFRA type, the PRACH resources used therein may be intentionally or dedicatedly allocated to the UE via RRC configuration or an early RACH command as described above. For an early RACH procedure of the CBRA type, the PRACH resources used therein may be selected by the MAC entity of the UE from the allocated common PRACH resources, which may require contention resolution with other UEs. In some example implementations, if an early RACH procedure of the CBRA type is initiated, it may no longer be necessary Figure 5 The Msg 3 and Msg 4 of the normal RACH procedure shown and described above are because the only purpose of the UE's early RACH procedure is to obtain the TA before the LTM and, unlike the normal RACH procedure, is not intended to actually perform any uplink transmission. In other words, when the RAR (i.e. Figure 5 When Msg 2) is received, the UE may consider that the early RACH based on CBRA has been successfully terminated.

[0096] The UE may determine the type of early RACH procedure (CBRA or CFRA) in various example ways:

[0097] If the PRACH resource (e.g., preamble ID and / or PRACH MASK) and SSB ID / CSI-RS ID are not present in the early RACH order 710, or the PRACH resource such as the preamble ID is presented as 0b000000 in the early RACH order, the UE may determine that the early RACH procedure is of CBRA type. Otherwise, the early RACH procedure may be determined to be of CFRA type.

[0098] If the PRACH resources indicated by the Early RACH order are from UE-dedicated RACH resources, the UE may determine that the Early RACH procedure is of CFRA type. However, if the PRACH resources indicated by the Early RACH order are from cell-specific RACH resources, the UE may determine that the Early RACH procedure is of CBRA type.

[0099] • The RACH type of the early RACH may be indicated by an information element configured in the RRC configuration associated with the candidate cell, and the UE may determine the type of the early RACH procedure based on the RRC information element.

[0100] In some example embodiments, as described above, RACH resources used for early RACH procedures may also be shared with RACH resources used for LTM-based cell switching. In this case, if the target of the early RACH procedure is a candidate cell that belongs to a different DU than the DU associated with the current serving cell (inter-DU case), the candidate cell may follow various example solutions to distinguish early RACH requests from RACH requests for LTM.

[0101] Such a solution can be RRC-based. For example, when using UE-specific RACH resources, the PRACH resources used for early RACH can be separated from the PRACH resources used for RACH-based LTM. In other words, some UE-specific RACH resources can be configured to be dedicated to early RACH procedures, while some other UE-specific RACH resources can be configured to be dedicated to RACH-based LTM procedures. Candidate cells can thus distinguish between early RACH requests and RACH requests for LTM-based cell handover based on the RACH resources used by the received requests.

[0102] The solution may alternatively be based on a MAC CE. For example, in the case of early CFRA, the UE, after sending an early RACH request and receiving a RAR from the candidate cell, may additionally send a MAC CE to the candidate cell, wherein the UL grant includes the received RAR to inform the candidate cell of the purpose of the RACH (e.g., whether it is an early RACH for acquiring TA or a RACH procedure for RACH-based LTM). In some example embodiments, the presence of a C-RNTI MAC CE in an UL transmission by the UE using the UL grant indicated in the RAR received from the candidate cell may be regarded by the candidate cell as an indication that the current RACH is for LTM-based cell switching. Otherwise, when an UL transmission by the UE using the UL grant indicated in the received RAR or the UL grant indicated in the received RAR is ignored by the UE, or an UL transmission with zero padding is received by the candidate cell, for example, it may be regarded as an indication that the current RACH procedure is an early RACH for obtaining TA acquisition only. In another example embodiment, the UE uses the UL grant indicated in the RAR received from the candidate cell to include a specific UL MAC CE in the UL transmission, which can be regarded by the candidate cell as an indication that the current RACH is an early RACH for acquiring the TA. In this example embodiment, the specific UL MAC CE is a MAC CE that only contains a subheader and does not contain any payload information.

[0103] For another example, in the case of early CBRA, in one example embodiment, when RAR (or Figure 5 In this case, the candidate cell, without receiving any UL transmission based on the RAR, may determine that the current RACH procedure (associated with the RAR it just sent to the UE) is an Early RACH procedure for acquiring a TA. In another example embodiment, the UE may include UL transmission (or Figure 5 The specific UL MAC CE in Msg.3) in the RACH is used to inform the candidate cell that the RACH is an early RACH for obtaining the TA value. In this exemplary embodiment, the specific UL MAC CE is a MAC CE that only includes a subheader but does not include any payload information.

[0104] Early RACH execution

[0105] Figure 8 The flowchart 800 in FIG. 1 shows in more detail Figure 7 Example implementation of the actual early RACH procedure of 730. Figure 8 As shown, in step 1, UE 802 may first send a RACH preamble 810 for early RACH to the candidate cell 806, as indicated by the early RACH command described above. Thereafter, the example early RACH procedure may differ in details depending on whether the DUs associated with the current serving cell and the candidate cell are different (inter-DU) or the same (intra-DU). In addition, the example early RACH procedure may or may not require RAR. Thus, four different scenarios may be possible: (1) intra-DU with RAR; (2) inter-DU with RAR; (3) intra-DU without RAR; and (4) inter-DU without RAR, where the corresponding example early RACH procedures are shown in the dashed boxes of 820, 830, 840, and 850, respectively.

[0106] In the example process 820, where the current serving cell 804 and the candidate cell 806 belong to the same DU (within a DU, where DUx and DUy are the same DU), and RAR is used to convey the TA, after step 1 above of sending the RACH preamble 810, the following steps of the early RACH procedure may be performed:

[0107] In step 2.a., the candidate cell sends a RAR 822 to the UE, and the TA information of the candidate cell 806 may be included in the RAR.

[0108] In step 3.a., to notify the current serving cell 804 of the UE 802 to switch back to the current serving cell 804, the UE may generate a handover notification 823 for the current serving cell 804. In some implementations, this step may not be required because the current serving cell and the candidate cell are preset by the same DU.

[0109] Alternatively, step 2 can be implemented as Figure 8 806, and the TA information of the candidate cell is included in the RAR. This is possible because the current serving cell 804 and the candidate cell 806 belong to the same DU, and therefore the RAR processing can be handled in a unified manner. In this alternative, the current serving cell will know that the UE will automatically switch back to receive the RAR within the RA response window.

[0110] In the example process 830, where the current serving cell 804 and the candidate cell 806 belong to different DUs (inter-DU, where DUx and DUy are different DUs) and RAR is used to convey the TA, after the above step 1 of sending the RACH preamble 810, the following steps of the early RACH procedure may be implemented:

[0111] In step 2.a., the candidate cell 806 may send a RAR 832 to the UE 802, and the TA information of the candidate cell 806 may be included in the RAR.

[0112] In step 3.a., in order to notify the current serving cell 804 of the UE 802 to switch back to the current serving cell 804, the UE may generate a handover notification 833 for the current serving cell 804.

[0113] Alternatively, the above steps 2.a. and 3.a. can be implemented as follows and Figure 8 Steps 2.b. and 3.b. in the following example:

[0114] In step 2.b, DUy associated with the candidate cell 806 may initiate, for example, an F1 interface procedure to inform DUx associated with the current cell 804 of the TA information of the candidate cell 806.

[0115] In step 3.b, the current serving cell 804 of the DUx may generate and send a RAR 836 to the UE, where the TA value of the candidate cell 806 is included in the RAR.

[0116] In the example process 840, where the current serving cell 804 and the candidate cell 806 belong to the same DU (within a DU, where DUx and DUy are the same DU) and RAR is not used to convey the TA, after the above step 1 of sending the RACH preamble 810, the following step 2 for the early RACH process indicated by 842 may be implemented: the DU (which is the same DU for both the candidate cell 806 and the current serving cell 804) may calculate the TA value of the candidate cell 806 via the early RACH. This is possible because the DU has direct information about both cells.

[0117] In the example process 850, where the current serving cell 804 and the candidate cell 806 belong to different DUs (inter-DU, where DUx and DUy are different DUs) and RAR is not used to convey TA, after the above step 1 of sending the RACH preamble 810, the following steps may be performed:

[0118] Step 2: DUy associated with the candidate cell 806 may initiate, for example, an F1 interface procedure to inform DUx associated with the current serving cell 804 of the TA information of the candidate cell, as indicated by 852. DUx may thereby maintain the acquired TA of the candidate cell 806 or send the acquired TA to UE 802 for maintenance.

[0119] Step 3: The UE 802 notifies the DUx associated with the current serving cell 804 to switch back to the current serving cell 804 , as indicated by 854 .

[0120] In some example implementations of 830 and 850 (inter-DU case), additional procedures may be considered to ensure that the current serving cell 804 and its DUx are aware that the UE is returning to the current serving cell after acquiring the TA.

[0121] For example, once the UE returns to the current serving cell 804 after acquiring the TA of the candidate cell 806, the UE 802 may trigger a scheduling request (SR) and send it to the current serving cell 804. For another example, the UE 802 may send a sounding reference signal (SRS) to the current serving cell 806 to indicate its return to the current serving cell.

[0122] For another example, after obtaining the TA of the candidate cell 806 or sending a preamble to the candidate cell 806, the UE 802 may generate a UL MAC CE and send it to the current serving cell 806 to notify the handover. In one example embodiment, when there are no UL-SCH resources available for the source serving cell 804 to accommodate the triggered UL MAC CE, an SR may be triggered. In another example, the UL MAC CE may be a UL Timing Advance Sync MAC CE as described below.

[0123] For another example, when the RAR does not exist, the timing at which DUx receives the F1 message 852 containing TA information associated with the UE and the candidate cell from DUy may be used as an indication for the UE to return to the current serving cell 804 .

[0124] For another example, the current serving cell 804 or the candidate cell 806 can configure an EarlyRACH-ControlTimer for the UE 802 to initiate an Early RACH procedure with the candidate cell 806. For example, the EarlyRACH-ControlTimer can be the number of preamble transmissions used to perform Early RACH. For another example, the EarlyRACH-ControlTimer can be the number of milliseconds used to perform Early RACH. The function of this timer on the UE 802 side can be configured as follows:

[0125] Start / restart after receiving an early RACH command.

[0126] • Stop after: receiving a RAR, or switching back to the serving cell 804, or receiving a DCI addressed by the C-RNTI for UL or DL ​​transmission.

[0127] Upon expiration, stop the ongoing Early RACH (if any) and switch back to the current serving cell 804 immediately.

[0128] In the example implementation within the DU, assume that the candidate cell 806 ( Figure 8 If there is an RAR in 820), the RAR (for example, in 824) can still include the UL grant of the current serving cell 804, which can then be used by the UE to notify the current serving cell 804 of its return after obtaining the TA of the candidate cell 806.

[0129] In the example implementation of the above-described inter-DU scenario 830, where the RAR is received by the UE 802 from the candidate cell 806, additional procedures may be implemented so that the UE 802 notifies the current serving cell 804 of the received TA information of the candidate cell 806. For example, a UL MAC CE (e.g., a UL TASync MAC CE) may be used to notify the current serving cell 804 of the successfully obtained time alignment timer (TAT) value of the candidate cell 806. To keep the TA aligned between the UE and the network, the UL Timing Advance Sync MAC CE may include at least one of the following mechanisms:

[0130] • TA synchronization may be triggered and pending by successfully receiving and decoding the RAR on the candidate cell 806 .

[0131] The MAC entity may generate a UL TA Sync MAC CE when there is an available UL-SCH that can accommodate the UL TA Sync MAC CE on the serving cell 804. In some example embodiments, the current serving cell 804 may be a SpCell. In some other embodiments, the current serving cell 804 may be a SCell or a SpCell.

[0132] • If no UL-SCH resources are available to accommodate the UL TA Sync MAC CE, an SR may be triggered and pending.

[0133] • TAT may be restarted / started when UL TA Sync MAC CE MAC CE is sent to the network.

[0134] In some example embodiments, the UL Timing Advance Sync MAC CE may include at least one of the following fields:

[0135] TA value, used to indicate the TA value of the candidate cell 806 and / or timing advance group (TAG) with respect to the current serving cell 804.

[0136] Candidate cell information, used to indicate the candidate cell where the TA is located.

[0137] TAG information, used to indicate the tag for which the obtained TA is targeted.

[0138] Left TAT length, used to indicate the left TAT length of the TAT value. The left length of the TAT is calculated based on the time of sending the UL timing advance Sync MAC CE.

[0139] In the above-mentioned example implementations (e.g., 820 and 830) in which RAR is present, the TAG may be configured in the RRC configuration or LTM configuration of the candidate cell (group) in various example ways. For example, a set of TAGs, such as auxiliary TAGs (aTAGs), may be introduced for each candidate cell group, and the aTAGs may be classified as PaTAGs, SaTAGs. For another example, only timeAlignmentTimer may exist in the candidate cell group configuration for signaling optimization. For another example, a global TAG ID pool may be used for TAGs of all cells (e.g., all serving cells) in a serving cell group and a candidate cell group (e.g., all candidate cells). For another example, a set of TAGs may be introduced for each candidate DU, which means that candidate (serving) cell groups belonging to the same DU share a TAG ID pool.

[0140] In the various example embodiments described above where RAR is not present (e.g., Figure 8 In the embodiment of 840 and 850 of , various factors may be considered when determining whether to terminate the early RACH process. For example, an information element may be included in the RRC configuration or LTM configuration of the candidate cell (group) to indicate the maximum number of preamble transmissions for the early RACH (or early RACH command) instructed by the PDCCH. The maximum number of transmissions may be tracked independently of other RACH types. If the number of preamble transmissions reaches the configured maximum number of preamble transmissions, the UE may consider that the early RACH has been successfully terminated. For another example, a hard-coded number N for the maximum number of preamble transmissions for the early RACH may be specified, such as N=1, N=2, etc.

[0141] Similar to LTE RACH-free TA acquisition

[0142] In some other example embodiments, TA acquisition may be RACH-free rather than based on a RACH procedure. For example, TA acquisition may be assumed, may be based on RRC, or may be based on MAC CE.

[0143] For example, in some embodiments, the TA of the candidate cell may be assumed to be zero due to the candidate cell being in close proximity to the UE.

[0144] For another example, the TA of another cell in the same TAG as the target cell may be known, and the TA of this cell may be used to approximate the TA of the candidate cell, assuming that the TAs of cells in the same TAG are similar.

[0145] In some examples, the TA of the candidate cell can be provided by RRC. For example, an information element associated with the candidate cell in the RRC configuration can be used to indicate the TA of the candidate cell, for example, 0. Furthermore, if the TA of the candidate cell is indicated as 0, the ID of the TAG to which the candidate cell belongs may not be included in the RRC configuration regarding the TA. Otherwise, the TAG ID may be included in the RRC configuration so that the UE can use the TA of another cell within the TAG (if known) to determine the TA of the candidate cell.

[0146] Similarly, the TA of the candidate cell can be provided via a MAC CE. For example, a field in the cell handover MAC CE can be included to indicate the TAG to which the candidate cell belongs, so that the UE can use the TA of a cell within the TAG (if known) to approximate the TA of the candidate cell. For another example, a field in the cell handover MAC CE can be included and used to directly indicate the TA of the candidate cell.

[0147] LTM switching process

[0148] As described above, LTM-based cell handover can be RACH-based or RACH-free, and the TA of the candidate cell or target cell obtained in the various exemplary manners described above can be used for uplink transmission timing in RACH-free LTM. Otherwise, the TA can be obtained through the RACH procedure in RACH-based LTM handover. Figure 9 Example general steps of an LTM switching process are shown in flowchart 900, including:

[0149] Step 1: The source cell 904 may first send an LTM initiation command, such as an LTM MAC CE, to the UE 902 to trigger LTM, as shown in 910 .

[0150] Step 2: UE 902 may then perform one or more operations of cell switching according to the received LTM MAC CE, as indicated by 920 .

[0151] • Step 3: The UE 902 and target cell 906 may then interact to establish communications and complete the cell handover via a RACH-based procedure (as shown at 930) or a RACH-less procedure (as shown at 940), as described in further detail below.

[0152] Step 4: If the UE 902 determines that the cell handover fails, it may further perform a set of operations as described in detail below.

[0153] For step 1 shown in 910, the LTM MAC CE in L2 from the source cell 904 to the UE 902 may include at least one of the following information items:

[0154] Target cell group configuration ID, used to indicate the target cell group to which the target cell 906 belongs.

[0155] Target SpCell ID, used to identify the target cell 906 to which the UE 902 is to be handed over.

[0156] L2 (Layer 2) reset indication, used to indicate whether an L2 reset is required.

[0157] Bandwidth Part (BWP) ID, used to indicate the UL BWP and DLBWP of the target cell to be used by the UE 902 during handover.

[0158] • A TA field, used to indicate the TA value of the target cell 906. In some example embodiments, if RAR is indicated as available according to an indication associated with the candidate cell group, the TA field here may be reserved for the R bit.

[0159] Cell Radio Network Time Identifier (C-RNTI), used to indicate the C-RNTI used by UE 902 when accessing target cell 906. In some example embodiments, this may be optional. If a C-RNTI value is present in the RRC configuration associated with target cell 906, this field may be reserved for the R bit.

[0160] Step 2 Figure 9 920), UE 902 may perform one or more operations for cell handover according to the LTM MAC CE or LTM handover command 910 in step 1. For example, if so indicated in the LTM MAC CE, the one or more operations may include an L2 reset.

[0161] In some example embodiments, at least one of the following operations associated with an L2 reset may be employed:

[0162] • PDCP resumption for Acknowledged Mode (AM) Data Radio Bearers (DRBs), if any.

[0163] • RLC re-establishment for all data radio bearers.

[0164] Full MAC reset.

[0165] Otherwise, if the LTM MAC CE 910 does not indicate an L2 reset, the UE 902 may perform an adaptive MAC reset or a partial MAC reset or an LTM MAC reset.

[0166] In the above example implementation, adaptive MAC reset can be a subset of full MAC reset. Full MAC reset operations can be categorized into the following categories:

[0167] MAC reset operations handled by the MAC entity include but are not limited to:

[0168] o stop the ongoing random access procedure (if any);

[0169] o discarding the explicitly signaled contention-free random access resources (if any) for 4-step RA type and 2-step RA type;

[0170] o flush for 4-step RA (e.g., Figure 5 Msg3 buffer of the process);

[0171] ο Clear the MSGA buffer of 2-step RA;

[0172] o Release the temporary C-RNTI (if any).

[0173] MAC reset operation handled by HARQ entity:

[0174] o Clear the RA for 4 steps (e.g. Figure 5 Msg 3 buffer of the process);

[0175] ο Clear the MSGA buffer for 2-step RA; set the NDI of all uplink HARQ processes to the value 0;

[0176] o flushing the soft buffers for all DL and UL HARQ processes;

[0177] o For each DL HARQ process, the next received TB transmission is considered as the first transmission.

[0178] MAC reset operation handled by logical channel:

[0179] ο Initialize Bj of each logical channel to zero;

[0180] o cancel the triggered recommended bitrate query process (if any); or

[0181] o cancel the triggered buffer status reporting process (if any);

[0182] o Cancel the triggered scheduling request process (if any).

[0183] MAC reset operation handled by CC / BWP:

[0184] o cancel the triggered power headroom reporting procedure (if any);

[0185] o cancel the triggered persistent listen-before-talk (LBT) failure (if any);

[0186] o cancel the triggered beam failure recovery (BFR) (if any);

[0187] o cancel the triggered configured uplink grant confirmation (if any);

[0188] o cancel the triggered query of the required protection symbols (if any);

[0189] o reset all beam fault indicator (BFI) counters; or

[0190] ο Reset all LBT counters.

[0191] MAC reset operations processed by TAG:

[0192] o Treat all time_Aligament_Timers as expired and perform corresponding actions.

[0193] Based on each of the above categories of MAC reset operations, several general considerations may be included in the implementation of MAC reset in LTM, including but not limited to:

[0194] • All MAC reset operation items in the category handled by MAC entity can be included as being valid in LTM MAC reset.

[0195] • All MAC reset operation items in the category of HARQ entity processing can be included as valid in LTM MAC reset.

[0196] If the associated DRB is modified / released by taking into account the pre-configured LTM configuration, all MAC reset operation items in the category handled by LCH (except "Cancel Triggered Scheduling Request Procedure (if any)") can be included as valid in the LTM MAC reset. In one embodiment, DRBs included in drbtoAddmodList or SCelltoReleaseList can be considered as modified / released. In another embodiment, for LTM within a DU, DRBs can be considered as not modified / released.

[0197] For serving cells that are modified / released by considering the pre-configured candidate cell group configuration for LTM application, all MAC reset operations in the CC / BWP processing category can be included as valid in LTM MAC reset. In one embodiment, the serving cell can be an SCell included in the SCelltoAddModList or SCelltoReleaseList that is considered to be modified / released. In another embodiment, the serving cell can be an SpCell that is considered to be modified / released.

[0198] For MAC reset operations in the category processed by TAG, it shall not be included in the LTM MAC reset.

[0199] • For timer operations, stop all timers associated with the cancelled MAC process.

[0200] For a partial MAC reset or LTM MAC reset, it may include at least one of the following information:

[0201] Stop the ongoing random access procedure (if any);

[0202] Discarding the explicitly signaled, contention-free random access resources (if any) for 4-step RA type and 2-step RA type;

[0203] Clear all targets for 4-step RA (e.g. Figure 5 Msg 3 buffer of the process);

[0204] Clear the MSGA buffer of the 2-step RA;

[0205] Release the temporary C-RNTI (if any);

[0206] Set the NDI value for all uplink HARQ processes to 0;

[0207] Flushing the soft buffers for all DL and UL HARQ processes;

[0208] For each DL HARQ process, treat the next received TB transmission as the first transmission

[0209] Cancel the triggered scheduling request process (if any);

[0210] If the DRB associated with the LCH is released and / or modified by taking into account the pre-configured LTM configuration, at least one of the following MAC operations is included:

[0211] ο Initialize Bj of the logical channel to zero;

[0212] o cancel the triggered recommended bitrate query process (if any);

[0213] If the serving cell is released and / or modified by taking into account the pre-configured LTM configuration, at least one of the following MAC operations is included:

[0214] o cancel the power headroom reporting procedure triggered for the serving cell (if any);

[0215] o Cancel the consecutive listen-before-talk (LBT) failures triggered for the serving cell (if any) and / or reset the corresponding LBT_COUNTER;

[0216] o cancelling the beam failure recovery (BFR) triggered for the serving cell (if any), and / or

[0217] Or reset the corresponding BFI-COUNTER.

[0218] o Cancel the configured uplink grant confirmation triggered for the serving cell (if any).

[0219] o Cancel the required guard symbol query triggered for the serving cell (if any).

[0220] For step 3 ( Figure 9 930 or 940), the RACH-based LTM process (930) or the RACH-free (or RACH-free) LTM process may be selected in the following manner:

[0221] In some example embodiments, if the TA value maintained at the UE side is valid for the TAG to which the target cell belongs, RACH-less or RACH-free LTM may be selected. Otherwise, RACH-based LTM is selected.

[0222] In some other example embodiments, if the TA value is not present in either the LTM MAC CE or the RRC configuration of the target cell, RACH-based LTM may be selected. Otherwise, RACH-less or RACH-free LTM is selected.

[0223] For RACH-based LTM 930 including step 3a, detailed steps 932 to 938 may follow Figure 5 The general 4-step RACH process includes, for example:

[0224] In 932, UE 902 may select a preamble and send it to the target cell. The RACH preamble ID may be selected based on the reference signal ID indicated in the LTM MAC CE through the mapping of reference signals to RACH preambles.

[0225] • In 934, the target cell 906 may send a RAR to the UE.

[0226] • UE 902 may send Msg 3 with UL grant included in RAR to target cell 906.

[0227] The target cell 906 may send Msg 4 to the UE 902.

[0228] When the RACH procedure 930 is successfully completed and terminated, the LTM procedure may be considered successful.

[0229] For RACH-free or RACH-free LTM 940, steps 3b.1 (942) and 3b.2 (944) are included. In step 3b.1, as shown in 942, UE 902 sends a notification of UE arrival to target cell 906. In step 3b.2, UE 902 receives an acknowledgment of the notification from target cell 906. The notification of UE arrival in 942 may include, for example, at least one of the following:

[0230] Use a configured grant type 1 to carry the C-RNTI MAC CE, with each type 1 configured grant associated with a reference signal (e.g., similar to the solution for Configured Grant Small Data Transmission (CG-SDT)). In one embodiment, the reference signaling can be an SSB or CSI-RS.

[0231] • Send an SRS to the target cell, which has been associated with the reference signal or TCI state ID in the SRS-Config of the target cell. In one embodiment, the reference signaling can be SSB or CSI-RS.

[0232] For step 4, if Figure 9 As shown in 950, the UE may determine whether the cell handover has failed based on a network confirmation or a NACK. The network confirmation or NACK may be received or determined in the following example manners:

[0233] The determination of LTM success may be based on the network confirmation response to the notification from the target cell 906:

[0234] o If the LTM is a RACH-based LTM, the successful termination of the RACH procedure may be used as a network acknowledgement response.

[0235] o If the LTM is a RACH-less LTM, the reception of the DCI scrambled with the new C-RNTI may be considered as a network acknowledgement response.

[0236] o The receipt of the DL MAC CE may be regarded as a network confirmation response.

[0237] LTM failure determination can be based on network NACK responses:

[0238] o If the LTM is a RACH-based LTM, the failure of the RACH procedure may be used as a NACK response.

[0239] o If the LTM is a RACH-less LTM, then the expiration of the timer may be considered a network NACK response.

[0240] When the ACK is received from the network and / or the ACK is determined by the UE, the LTM process is considered to be successfully terminated. However, when the NACK is received from the network or the NACK is determined by the UE, the LTM is considered to be unsuccessful. If the UE determines that the LTM process is unsuccessful, the following example process may be further adopted:

[0241] The UE may trigger the RRC re-establishment procedure.

[0242] • The UE may revert back to the source serving cell (e.g., by automatically performing a cell handover back to the source cell by applying a pre-configured cell group configuration associated with the source cell(s)).

[0243] • If more than one candidate target cell is provided in the LTM MAC CE or candidate cell group configuration, the UE may perform the next LTM on the next candidate cell randomly or sequentially.

[0244] In some example implementations, additional procedures or considerations may be employed after the LTM cell is handed over to the target SCell. Such SCell operations / considerations may include, but are not limited to:

[0245] When no SCell exists in either SCelltoReleaslist or SCellToAddModList in the candidate cell group configuration, the SCell is considered to be activated during LTM-based cell handover.

[0246] • According to the indication from the LTM MAC CE, the SCell is considered to be activated during LTM based cell handover, for example, the LTM MAC UE may include a bitmap of SCell indication.

[0247] The above description and accompanying drawings provide specific example embodiments and implementation schemes. However, the subject matter described may be embodied in a variety of different forms, and therefore, the subject matter covered or claimed is intended to be construed as not being limited to any example embodiment set forth herein. A reasonable range of subject matter is claimed or covered. For example, the subject matter may be embodied as a method, device, component, system, or non-transitory computer-readable medium for storing computer code, among other things. Thus, the embodiments may, for example, take the form of hardware, software, firmware, storage media, or any combination thereof. For example, the above method embodiments may be implemented by a component, device, or system comprising a memory and a processor by executing computer code stored in the memory.

[0248] Throughout the specification and claims, terms may have nuanced meanings that are suggested or implied by the context, beyond those explicitly stated. Similarly, the phrase "in one embodiment / implementation" used herein does not necessarily refer to the same embodiment, and the phrase "in another embodiment / implementation" used herein does not necessarily refer to a different embodiment. For example, claimed subject matter includes all or part of the combination of the example embodiments.

[0249] In general, terms can be understood, at least in part, from their usage in context. For example, terms such as "and," "or," or "and / or," as used herein, can include multiple meanings that depend, at least in part, on the context in which the terms are used. Typically, "or," if used in an associative list, such as A, B, or C, means A, B, and C, where used in an inclusive sense, and A, B, or C, where used in an exclusive sense. Additionally, the term "one or more," as used herein, can be used to describe any feature, structure, or characteristic in a singular sense, or can be used to describe a combination of features, structures, or characteristics in a plural sense, depending, at least in part, on the context. Similarly, terms such as "a," "an," or "the" can be understood to mean either singular or plural usage, depending, at least in part, on the context. Additionally, the term "based on" can be understood to not necessarily be intended to convey a set of exclusive factors, and can allow for the presence of additional factors that are not necessarily explicitly described, depending, at least in part, on the context.

[0250] References throughout this specification to features, advantages, or similar language do not imply that all features and advantages that may be implemented with the present solution should be or are included in any single embodiment thereof. Rather, language referring to 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 features and advantages, and similar language, throughout this specification may, but do not necessarily, refer to the same embodiment.

[0251] Furthermore, in one or more embodiments, the described features, advantages, and characteristics of the present solution may be combined in any suitable manner. Based on the description herein, one of ordinary skill in the relevant art will recognize that the present solution may be practiced without one or more of the specific features or advantages of a particular embodiment. In other cases, additional features and advantages may be identified in a particular embodiment that may not be present in all embodiments of the present solution.

Claims

1. A method performed by a wireless terminal in communication with a current serving cell, the method comprising: receiving a timing advance (TA) configuration from the current serving cell to assist in obtaining a timing advance (TA) associated with a candidate cell; Acquire the TA according to the TA configuration; receiving a Layer 1 / Layer 2 Triggered Mobility (LTM) command instructing the wireless terminal to perform a cell handover to the candidate cell; as well as Performing a random access-free cell handover from the current serving cell to the candidate cell according to the LTM command.

2. The method according to claim 1, wherein Acquiring the TA according to the TA configuration includes: performing an early random access procedure on the candidate cell, where the early random access procedure is designed for acquiring a timing advance rather than for uplink data transmission.

3. The method according to claim 2, wherein: The early random access procedure is performed on a random access resource set configured in the TA configuration for early random access.

4. The method according to claim 3, wherein: The TA configuration is communicated to the wireless terminal from the current serving cell in a radio resource control (RRC) configuration message.

5. The method according to claim 3, wherein: The random access resource set is configured as cell-specific random access resources for non-exclusive use by the early random access procedure in a contention-based manner.

6. The method according to claim 3, wherein: The random access resource set is configured as UE-specific random access resources dedicated to the wireless terminal, so as to be used non-exclusively by the early random access procedure in a contention-free manner.

7. The method according to claim 6, wherein: The early random access procedure includes sending a random access preamble to the candidate cell; and The method also includes transmitting a control message to the candidate cell, the control message indicating to the candidate cell that the random access preamble sent by the wireless terminal is for early random access and TA acquisition, rather than uplink transmission.

8. The method according to claim 3, wherein: The random access resource set is configured as UE-specific random access resources dedicated to the wireless terminal for exclusive use by an early random access procedure.

9. The method of claim 3, further comprising determining a random access type of the early random access procedure before performing the early random access procedure, the random access type being one of a contention-based random access type or a contention-free random access type. 10 . The method according to claim 9 , further comprising determining that the early random access procedure is a contention-based random access type when the LTM command does not include identification information of the random access resource set.

11. The method according to claim 9, further comprising determining that the early random access procedure is a contention-free random access type when the LTM command includes identification information of a UE-specific random access resource.

12. The method according to claim 9, wherein Determining the random access type of the early random access procedure includes extracting an explicit type indicator in an RRC configuration associated with the set of random access resources configured for the early random access procedure.

13. The method according to claim 3, wherein: The current serving cell is preset by a first distributed unit base station, and the candidate cell is preset by a second distributed unit base station, which is different from the first distributed unit base station.

14. The method according to claim 13, wherein The TA configuration originates from the second distributed cell base station and is transmitted to the first distributed cell base station via a central cell base station before being transmitted by the first distributed cell base station and received by the wireless terminal.

15. The method according to claim 13, further comprising performing a notification procedure on the current serving cell to indicate to the current serving cell that the wireless terminal will return to the current serving cell after acquiring the TA.

16. The method according to claim 15, wherein The notification process includes: once the TA associated with the candidate cell is acquired, triggering and sending a scheduling request, sending a sounding reference signal (SRS), or sending a medium access control (MAC) control element (MAC CE) on the current serving cell.

17. The method of claim 13, further comprising sending a control message to the first distributed unit base station, the control message including the TA acquired by the wireless terminal.

18. The method according to claim 13, wherein The early random access procedure includes sending a random access preamble to the candidate cell and receiving a random access response from the first distributed unit base station associated with the current serving cell, the random access response being relayed by a central unit base station from the second distributed unit base station associated with the candidate cell.

19. The method according to claim 3, wherein The early random access procedure includes sending a random access preamble to the candidate cell and receiving a random access response message including the TA from the candidate cell.

20. The method according to claim 3, wherein The early random access procedure includes sending a random access preamble to the candidate cell and receiving a random access response message including a TA associated with the candidate cell from the candidate cell or the current serving cell, followed by terminating the early random access procedure.

21. The method of claim 3, wherein: The current serving cell and the candidate cell are preset by the same distributed unit base station; and The early random access procedure includes sending a random access preamble to the candidate cell and receiving a random access response associated with the candidate cell from the same distributed unit base station.

22. The method of claim 1, wherein: The TA configuration indicates to the wireless terminal that the TA associated with the candidate cell is to be approximated by cells within the same timing advance group (TAG) as the candidate cell; and Acquiring the TA according to the TA configuration includes: obtaining a known reference TA within the TAG as the TA associated with the candidate cell.

23. The method of claim 1, further comprising performing at least one Layer 2 reset operation after receiving the LTM command.

24. A wireless terminal comprising a processor and a memory, wherein: The processor is configured to read computer code from the memory to cause the wireless terminal to: receiving a timing advance (TA) configuration from a current serving cell of the wireless terminal to assist in acquiring a timing advance (TA) associated with a candidate cell; Acquire the TA according to the TA configuration; receiving a Layer 1 / Layer 2 Triggered Mobility (LTM) command instructing the wireless terminal to perform a cell handover to the candidate cell; and A cell handover without random access is performed from the current serving cell to the candidate cell according to the LTM command.

25. The wireless terminal according to any one of claims 2 to 23, comprising a processor and a memory, wherein: The processor is configured to read computer code from the memory to cause the wireless terminal to perform the method according to any one of claims 2 to 23.

26. A computer program product comprising a non-transitory computer-readable program medium having computer code stored thereon, the computer code, when executed by a processor of a wireless terminal according to any one of claims 1 to 23, causing the processor to implement the method according to any one of claims 1 to 23.

Images