Improvements relating to early synchronization in wireless communication systems

Abstract

The present disclosure relates to a 5th-Generation (5G) or 6th-Generation (6G) communication system for supporting higher data transmission rates. A method performed by a user equipment (UE) in a wireless communication system is provided. The method includes: receiving, from a base station, a physical downlink control channel (PDCCH) command for a random access procedure on a Layer 1 / Layer 2 triggered mobility (LTM) candidate cell; transmitting a random access preamble for early timing advance (TA) acquisition of the LTM candidate cell on the basis of the PDCCH command; and receiving, from the base station, a cell handover command including a TA value of the LTM candidate cell, in which a bandwidth part (BWP) operation is not performed on the LTM candidate cell based on the random access procedure being initiated by the PDCCH command.

Description

Technical Field

[0001] This disclosure relates to improvements in early synchronization in wireless communication systems. Background Technology

[0002] Fifth-generation (5G) mobile communication technology defines wide frequency bands, enabling high transmission rates and new services. It can be implemented not only in "sub-6GHz" bands such as 3.5GHz, but also in "above-6GHz" bands, including 28GHz and 39GHz, known as millimeter waves (mmWave). Furthermore, sixth-generation (6G) mobile communication technology (called "super 5G systems") is being considered in terahertz bands (e.g., the 95GHz to 3THz band) to achieve transmission rates 50 times faster than 5G and ultra-low latency one-tenth that of 5G.

[0003] In the early stages of 5G mobile communication technology development, to support services and meet performance requirements related to enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), and massive machine-type communication (mMTC), standardization has been ongoing for the following technologies: beamforming and massive multiple-input multiple-output (MIMO) for reducing radio wave path loss and increasing radio wave transmission distance in millimeter waves; support parameter sets for dynamic operation (e.g., operating multiple subcarrier spacings) for efficient utilization of millimeter wave resources and time slot formats; initial access technologies for supporting multi-beam transmission and broadband; definition and operation of bandwidth portions (BWP); new channel coding methods such as low-density parity-check (LDPC) codes for large-volume data transmission and polar codes for highly reliable transmission of control information; layer 2 (L2) preprocessing; and network slicing for providing dedicated networks for specific services.

[0004] Currently, regarding the services supported by 5G mobile communication technology, the industry is discussing improvements and performance enhancements to the initial 5G mobile communication technology, and physical layer standardization has been completed for technologies such as: Vehicle-to-Everything (V2X) for assisting autonomous vehicles in making driving decisions based on information sent by vehicles about their location and status and for improving user convenience; New Radio Unlicensed (NR-U) designed to comply with various regulatory requirements for system operation in unlicensed frequency bands; NR User Equipment (UE) power saving; Non-Terrestrial Networks (NTNs) for providing coverage in areas where UEs cannot communicate with terrestrial networks via direct satellite communication; and positioning.

[0005] Furthermore, standardization of air interface architectures / protocols for technologies such as: Industrial Internet of Things (IIoT) for supporting new services through interoperability and integration with other industries; Integrated Access and Backhaul (IAB) for providing nodes for network service area extension by supporting wireless backhaul and access links in an integrated manner; mobility enhancements including conditional handover and Dual Active Protocol Stack (DAPS) handover; and two-step random access (RACH for NR) for simplifying the random access process. Simultaneously, standardization of system architectures / services for technologies such as: 5G baseline architectures (e.g., service-based architectures or service-based interfaces) for combining Virtual Network Functions (NFV) and Software-Defined Networking (SDN) technologies; and Mobile Edge Computing (MEC) for receiving services based on UE location.

[0006] With the commercialization of 5G mobile communication systems, an exponential increase in connected devices will be added to communication networks, thus necessitating enhanced functionality and performance of 5G mobile communication systems as well as integrated operation of connected devices. To this end, new research is planned related to the following technologies: Extended Reality (XR) for efficient support of Augmented Reality (AR), Virtual Reality (VR), Mixed Reality (MR), etc.; 5G performance improvements and complexity reduction through the utilization of Artificial Intelligence (AI) and Machine Learning (ML); AI service support; Metaverse service support; and drone communication.

[0007] Furthermore, this development of 5G mobile communication systems will not only lay the foundation for the development of technologies such as: new waveforms for providing coverage in the terahertz band of 6G mobile communication technology; multi-antenna transmission technologies such as full-dimensional MIMO (FD-MIMO), array antennas, and massive MIMO; metamaterial-based lenses and antennas for improving coverage of terahertz band signals; high-dimensional spatial multiplexing technologies using orbital angular momentum (OAM); and reconfigurable smart surfaces (RIS), but will also lay the foundation for the development of technologies such as: full-duplex technologies for improving the frequency efficiency of 6G mobile communication technology and improving system networks; AI-based communication technologies for system optimization by leveraging satellites and artificial intelligence (AI) from the design stage and internalizing end-to-end AI support functions; and next-generation distributed computing technologies for providing services with a level of complexity exceeding the operational capabilities of UEs by utilizing ultra-high-performance communication and computing resources.

[0008] The above information is presented as background information only to aid in understanding this disclosure. No decision has been made, nor any assertion has been asserted, regarding whether any of the above content is applicable to prior art related to this disclosure. Summary of the Invention

[0009] [Solution to the problem]

[0010] A method is provided for execution by a user equipment (UE) in a wireless communication system. The method includes: receiving from a base station a physical downlink control channel (PDCCH) command for triggering a random access procedure on a Layer 1 / Layer 2 mobility (LTM) candidate cell; transmitting a random access preamble for early timing advance (TA) acquisition of the LTM candidate cell based on the PDCCH command; and receiving from the base station a cell handover command including the TA value of the LTM candidate cell, wherein the random access procedure is initiated by the PDCCH command and no bandwidth portion (BWP) operation is performed on the LTM candidate cell.

[0011] A method is provided to be performed by a base station in a wireless communication system. The method includes: sending a Physical Downlink Control Channel (PDCCH) command to a User Equipment (UE) for triggering a random access procedure on a Layer 1 / Layer 2 Mobility (LTM) candidate cell; and sending a cell handover command to the UE including a Timing Advance (TA) value of the LTM candidate cell, wherein the random access preamble for the early TA acquisition of the LTM candidate cell is based on the PDCCH command, and wherein the random access procedure is initiated by the PDCCH command without performing a Bandwidth Partial (BWP) operation on the LTM candidate cell.

[0012] A user equipment (UE) is provided in a wireless communication system. The UE includes a transceiver and a controller connected to the transceiver, the controller being configured to: receive from a base station a physical downlink control channel (PDCCH) command for triggering a random access procedure on a Layer 1 / Layer 2 mobility (LTM) candidate cell; transmit a random access preamble for early timing advance (TA) acquisition of the LTM candidate cell based on the PDCCH command; and receive from the base station a cell handover command including the TA value of the LTM candidate cell, wherein the random access procedure is initiated by the PDCCH command and no bandwidth portion (BWP) operation is performed on the LTM candidate cell.

[0013] A base station is provided in a wireless communication system. The base station includes a transceiver and a controller connected to the transceiver. The controller is configured to send a Physical Downlink Control Channel (PDCCH) command to a User Equipment (UE) for triggering a random access procedure on a Layer 1 / Layer 2 Mobility (LTM) candidate cell; and to send a cell handover command to the UE including a Timing Advance (TA) value of the LTM candidate cell, wherein the random access preamble for obtaining the early TA of the LTM candidate cell is based on the PDCCH command, and wherein the random access procedure is initiated by the PDCCH command without performing a Bandwidth Partial (BWP) operation on the LTM candidate cell.

[0014] Various aspects of this disclosure are intended to at least address the aforementioned problems and / or disadvantages, and to provide at least the advantages described below. Therefore, one aspect of this disclosure is intended to provide improvements regarding early synchronization in wireless communication systems.

[0015] Other aspects will be set forth in part in the description which follows, and will be apparent in part from the description, or may be learned by practice of the presented embodiments.

[0016] Other aspects, advantages, and distinctive features of this disclosure will become apparent to those skilled in the art from the following detailed description of various embodiments thereof, taken in conjunction with the accompanying drawings. Attached Figure Description

[0017] The above and other aspects, features, and advantages of certain embodiments of this disclosure will become more apparent from the following description taken in conjunction with the accompanying drawings, in which: Figure 1 Signaling procedures for a Local Service Manager (LTM) according to embodiments of this disclosure are illustrated; Figure 2 The early transport configuration indicator (TCI) state activation process according to an embodiment of this disclosure is illustrated; Figure 3 An early technology assessment (TA) acquisition process according to an embodiment of this disclosure is illustrated; Figure 4 The UE state machine and state transitions in an NR according to an embodiment of this disclosure are shown; Figure 5 An LTE system according to an embodiment of this disclosure is shown; Figure 6 The wireless protocol structure in an LTE system according to an embodiment of the present disclosure is shown; Figure 7 A next-generation mobile communication system according to an embodiment of the present disclosure is shown; Figure 8 The wireless protocol structure of a next-generation mobile communication system according to an embodiment of the present disclosure is shown; Figure 9 A message stream illustrating a successful Radio Resource Control (RRC) reconfiguration is shown according to an embodiment of this disclosure; Figure 10 A message stream illustrating an RRC reconfiguration failure is shown according to an embodiment of this disclosure; Figure 11 Various random access procedures according to embodiments of this disclosure are illustrated; Figure 12 A fallback for contention-based random access (CBRA) with a 2-step RA type is illustrated according to an embodiment of this disclosure; Figure 13 An octet of the SCell activation / deactivation media access control (MAC) control element (CE) according to an embodiment of the present disclosure is shown. Figure 14 This illustrates a SCell activation / deactivation MAC CE with four octets according to an embodiment of this disclosure; Figure 15 An enhanced SCell activation / deactivation MAC CE with an octet Ci field is shown according to an embodiment of this disclosure; Figure 16 An enhanced SCell activation / deactivation MAC CE with four octet Ci fields is shown according to an embodiment of this disclosure; Figure 17 An example of a downlink (DL) MAC protocol data unit (PDU) according to an embodiment of this disclosure is shown; Figure 18 An example of a UL MAC PDU according to an embodiment of this disclosure is shown; Figure 19 A flowchart illustrating an embodiment of this disclosure is shown; Figure 20 A UE structure according to an embodiment of this disclosure is shown; and Figure 21 The structure of a base station according to an embodiment of the present disclosure is shown.

[0018] In all the accompanying drawings, the same reference numerals are used to denote the same elements. Detailed Implementation

[0019] The following description, provided with reference to the accompanying drawings, is intended to aid in a full understanding of the various embodiments of the present disclosure as defined by the claims and their equivalents. It includes various specific details to aid understanding, but these should be considered exemplary only. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the various embodiments described herein without departing from the scope and spirit of the present disclosure. Furthermore, for clarity and brevity, descriptions of well-known functions and structures may be omitted.

[0020] The terms and words used in the following description and claims are not limited to their dictionary meanings, but are used solely by the inventors to achieve a clear and consistent understanding of this disclosure. Therefore, it will be clear to those skilled in the art that the following description, which provides various embodiments of this disclosure, is for illustrative purposes only and is not intended to limit the disclosure as defined by the appended claims and their equivalents.

[0021] It should be understood that the singular forms “a,” “an,” and “the” include plural references unless the context clearly specifies otherwise. Thus, for example, referring to “the surface of a component” includes referring to one or more such surfaces.

[0022] It should be understood that each flowchart and the blocks in a combination of flowcharts can be executed by one or more computer programs including instructions. The entirety of the one or more computer programs can be stored in a single memory device, or the one or more computer programs can be divided into different parts stored in multiple different memory devices.

[0023] Any of the functions or operations described herein may be processed by a single processor or a combination of processors. The single processor or combination of processors is circuitry that performs the processing and includes, for example, an application processor (AP, such as a central processing unit (CPU)), a communication processor (CP, such as a modem), a graphics processing unit (GPU), a neural processing unit (NPU) (such as an artificial intelligence (AI) chip), a Wi-Fi chip, or Bluetooth. ® Circuits of chips, including Global Positioning System (GPS) chips, Near Field Communication (NFC) chips, connectivity chips, sensor controllers, touch controllers, fingerprint sensor controllers, display driver integrated circuits (ICs), audio codec chips, USB controllers, camera controllers, image processing ICs, microprocessor units (MPUs), system-on-a-chip (SoCs), ICs, or similar components.

[0024] This disclosure supports Layer 1 (L1) / Layer 2 (L2) triggered mobility (LTM) with low latency, low complexity, and no user plane (UP) data loss. It also considers the impact on legacy behaviors to ensure that this LTM cell handover feature does not conflict with them. Furthermore, methods are provided for supporting LTM cell handover for UEs configured with dual connectivity (DC), such as LTM cell handover for a secondary cell group (SCG). This disclosure also provides solutions for handling failures in LTM execution for rapid recovery.

[0025] Throughout the following description, some of the definitions listed below will be used: Physical Downlink Control Channel (PDCCH) Timing: Duration (i.e., one or more consecutive symbols) during which the MAC entity is configured to monitor the PDCCH.

[0026] Service cell: PCell, PSCell, or SCell.

[0027] Special Cell (SpCell): For dual-connectivity operation, the term "Special Cell" refers to the PCell of the Primary Cell Group (MCG) or the PSCell of the SCG, depending on whether the MAC entity is associated with the MCG or the SCG. Otherwise, the term "Special Cell" refers to the PCell. Special cells support PUCCH transmission and contention-based random access and are always active.

[0028] Timing Advance Group: A group of serving cells configured by RRC, which uses the same timing reference cell and the same timing advance value for cells configured with UL. The timing advance group of the SpCell containing the MAC entity is called the Primary Timing Advance Group (PTAG), while the term "Secondary Timing Advance Group (STAG)" refers to other TAGs.

[0029] msg3: A message sent on the UL-SCH containing a C-RNTI MAC control element (CE) or a common control channel (CCCH) service data unit (SDU), which is submitted from the upper layer and associated with the UE contention resolution identifier, and is part of the random access procedure.

[0030] LTM Candidate Cells: Candidate cells configured to the UE according to the LTM Candidate Cell Configuration (i.e., LTM-CandidateConfig) specified in the RRC layer.

[0031] Multiple Radio Dual Connectivity (MR-DC) is a generalization of E-UTRA Intra-Connectivity (DC), in which a UE supporting multiple Rx / Tx can be configured to utilize resources provided by two different nodes via a non-ideal backhaul connection, one node providing NR access and the other providing E-UTRA or NR access. One node acts as the MN (primary node or MCG (primary cell group)) and the other node acts as the SN (secondary node or SCG (secondary cell group)). The MN and SN are connected via a network interface, and at least the MN is connected to the core network.

[0032] MR-DC using EPC: E-UTRAN supports MR-DC via E-UTRA-NR dual connectivity (EN-DC), where the UE is connected to an eNB acting as the MN and an en-gNB acting as the SN. The eNB is connected to the EPC via the S1 interface and to the en-gNB via the X2 interface. The en-gNB can also be connected to the EPC via the S1-U interface and to other en-gNBs via the X2-U interface.

[0033] Utilizing 5GC's MR-DC: NG-RAN supports NG-RAN E-UTRA-NR dual connectivity (NGEN-DC), where the UE connects to one ng-eNB acting as the MN and one gNB acting as the SN. NG-RAN supports NR-E-UTRA dual connectivity (NE-DC), where the UE connects to one gNB acting as the MN and one ng-eNB acting as the SN. NG-RAN supports NR-NR dual connectivity (NR-DC), where the UE connects to one gNB acting as the MN and another gNB acting as the SN. Furthermore, NR-DC can also be used when the UE connects to a single gNB, which acts as both the MN and SN, and is configured with MCG and SCG.

[0034] In this paper, the term "cell handover" is used for the process of triggering a cell change via LTM features, and the term "follow-up LTM" is used for the case of a cell handover between L1 / L2 mobility candidates without RRC reconfiguration in between.

[0035] In addition, the LTM trigger MAC CE (i.e., LTE command MAC CE) is received to indicate the triggering of LTM cell handover execution (i.e., LTM cell handover process).

[0036] The purpose of this disclosure is to provide improvements to the field of LTM, particularly regarding synchronization.

[0037] According to this disclosure, an apparatus and method as described in the appended claims are provided. Other features of this disclosure will be apparent from the dependent claims and the following description.

[0038] To expedite the LTM cell handover process, it is beneficial to perform downlink and uplink synchronization before triggering the LTM cell handover execution, as the UE begins synchronizing with the network during LTM cell handover execution, which can lead to latency. In embodiments of this invention, as described herein, early downlink synchronization and early uplink synchronization are defined separately. Downlink (DL) and uplink (UL) bandwidth portion (BWP) processing is described, including how to activate / deactivate which BWP of the LTM candidate cell, and when to perform activation / deactivation, because in NR, the radio link between the network and the UE is maintained on a specific bandwidth portion (BWP) (e.g., initial BWP, default BWP, first active BWP, or dormant BWP), and the corresponding BWP behavior has a significant impact on UE energy saving. Specifically, the corresponding BWP behavior during early downlink / uplink synchronization is described. To maximize the benefits of early downlink / uplink synchronization, possible execution sequences are proposed. For early uplink synchronization, additional BWP behavior is defined for the newly defined random access procedure to avoid UE power consumption and conserve radio resources.

[0039] In early uplink synchronization, a new power ramping procedure is provided for MAC entities to increase the likelihood of success. Specifically, the more preambles the UE sends, the higher its transmit power, making early uplink synchronization more likely to succeed. To further enhance efficiency, additional conditions are provided to manage a variable called `PREAMBLE_POWER_RAMPING_COUNTER`. Furthermore, preamble (re)transmission is a primary action when the UE performs early uplink synchronization; therefore, preamble resources should be defined, such as when the UE retains or discards these resources. Parallel random access procedures are not supported in the prior art. However, another random access procedure can be triggered on the UE side during early uplink synchronization. New conditions are provided to avoid this. Additionally, several solutions to ensure the correct operation of LTM cell handover procedures are described.

[0040] According to a first aspect of this disclosure, a method is provided for a user equipment (UE) in a telecommunications network to perform random access for an early synchronization procedure, wherein the random access procedure is initiated on an LTM candidate cell by a PDCCH command, and if the PDCCH command indicates an initial transmission of a preamble, the UE is prohibited from performing specific actions related to BWP behavior.

[0041] In this embodiment, the specific action is one or more of the following actions: Send on the UL-SCH on the BWP; or Monitor PDCCH on BWP; or Monitor the PDCCH for BWP; or Send PUCCH on BWP; or Report CSI on BWP; or Send SRS on BWP; or Receive DL-SCH on BWP.

[0042] In this embodiment, the power ramp variable is increased.

[0043] According to a second aspect of this disclosure, an apparatus configured to perform the method of the first aspect is provided.

[0044] In this embodiment, the device is a UE.

[0045] Although several preferred embodiments of the present disclosure have been shown and described, those skilled in the art will understand that various changes and modifications may be made without departing from the scope of the present disclosure as defined by the appended claims.

[0046] To better understand this disclosure, and to illustrate how embodiments of this disclosure can be implemented, reference will now be made to the accompanying drawings by way of example only, wherein: LTM (Local Time Management) is a process in which the base station (gNB) receives L1 measurement reports from the user equipment (UE) and, based on these reports, changes the UE's serving cell via a cell handover command through a Media Access Control (MAC) control element (CE). This MAC CE indicates an LTM candidate cell configuration previously prepared by the gNB and provided to the UE via Radio Resource Control (RRC) signaling. Cell handover is then triggered by the gNB selecting the indicated LTM candidate cell configuration as the target configuration. LTM candidate cell configurations can only be added, modified, and released by the network via RRC signaling. The LTM procedure can be used to reduce mobility.

[0047] The network can request the UE to perform early timing advance (TA) acquisition (or TA acquisition) of the candidate cell (i.e., LTM candidate cell) before cell handover. Early TA acquisition (or TA acquisition) is triggered by physical downlink control channel (PDCCH) commands or by UE-based TA measurements.

[0048] In the cell handover command, the network indicates whether the UE should use a random access (RA) procedure to access the target cell (if no TA value is provided) or use the indicated TA value to access the target cell via the Physical Uplink Shared Channel (PUSCH). For LTM without RACH, the UE accesses the target cell via the configuration grant provided in the RRC signaling and selects the configuration grant timing associated with the beam indicated in the cell handover command.

[0049] If the UE does not receive a configuration grant in the RRC signaling, the UE monitors the PDCCH for dynamic scheduling from the target cell during LTM cell handover. If the UE does not have valid PUCCH resources for the triggered SR before the LTM procedure without RACH is completed, the UE will not trigger the random access procedure. The following principles apply to LTM: Each LTM candidate cell configuration can be provided as an incremental (delta) configuration based on a reference configuration, which is used to form the complete candidate cell configuration. The reference configuration can be managed separately, and the UE stores the reference configuration as a separate configuration. The LTM candidate cell configuration can be configured in the RRCReconfiguration message via SRB1 (e.g., signaling radio bearer), i.e., it can be configured after SRB1 is established.

[0050] - When the complete candidate cell configuration is applied, it replaces the current UE configuration during cell handover. Although the reconfiguration process performs a replacement, it does not necessarily reset the MAC, Radio Link Control (RLC), or Packet Data Convergence Protocol (PDCP) layers.

[0051] - When the user plane is configured in the RRC signaling, the user plane continues to operate without resetting to support lossless transmission of user plane data (e.g., LTM within a Distributed Cell (DU)). The goal is to avoid additional delays in data loss and data recovery. Specifically, indicators for RLC reconstruction or MAC reset (or partial MAC reset), or PDCP reconstruction or PDCP data recovery, or Service Data Unit (SDU) drop, as listed below, can be included in the RRCReconfiguration message. These indicators can be included along with the LTM candidate cell configuration: - Indicators for MAC reset or partial MAC reset included in RRCReconfiguration messages (e.g., in cell group (or cell) configuration). - Indicators for RLC reconstruction (e.g., reestablishRLC) included in the RRCReconfiguration message (e.g., in the cell group (or cell) configuration). - Indicators for PDCP reconstruction (e.g., reestablishPDCP) included in the RRCReconfiguration message (e.g., in the RadioBearerConfig IE). - Indicators for PDCP data recovery (e.g., recoverPDCP) included in the RRCReconfiguration message (e.g., in the radio bearer configuration (i.e., RadioBearerConfig IE)). - An indicator (e.g., discardOnPDCP) for SDU discarding of SRBs (e.g., SRB1 or SRB3) included in the RRCReconfiguration message (e.g., in the RadioBearerConfig IE), which may be referred to as PDCP SDU discard.

[0052] - The aforementioned indicators can be included in an RRCReconfiguration message containing candidate cell configurations for LTM (e.g., in cell group configuration or LTM candidate cell configuration). Upon receiving the RRCReconfiguration message, the UE can store the cell configurations and indicators and not apply them to the UE configuration. When the UE successfully completes an LTM procedure (or cell handover) after triggering it via a cell handover command via a MAC CE indicating the target cell (e.g., identifier), beam index, or timing advance (TA) value, the UE can apply the LTM candidate cell configuration and indicators corresponding to the target cell (or the cell indicated in the MAC CE). The following conditions are considered as the successful completion of the LTM procedure (i.e., cell handover): - For RACH-based LTM (cell handover) procedures, the UE considers the LTM execution process to be successfully completed when RACH is successfully completed.

[0053] - For LTM (cell handover) without RACH, the UE considers the LTM process to be successfully completed when it determines that the NW has successfully received its first UL data. The UE determines the successful reception of its first UL data based on the newly transmitted PDCCH addressing the UE's C-RNTI after receiving the scheduled first UL data in the target cell, and the UE considers the LTM process to be successfully completed.

[0054] When the conditions for successful LTM cell handover are met (or LTM cell candidate configuration is completed, i.e., if an indicator indicates that LTM cell candidate configuration should be applied), the UE can apply the LTM cell candidate configuration and indicator corresponding to the target cell (or the cell indicated in the MAC CE) to the UE configuration. This method avoids premature application by the UE and allows for recovery in case of UE failure, making UE implementation easier. Furthermore, the UE cannot know when the network sends the MAC CE indicating LTM cell handover to the UE.

[0055] For example, when the above conditions are met, if the indicator is configured in the stored configuration (e.g., LTM candidate cell configuration for LTM) corresponding to the target cell (or the cell indicated in the MAC CE or the cell successfully handed over), the UE performs a MAC reset (or partial MAC reset), which can be accomplished by applying the full LTM cell configuration. When the conditions are met, the MAC layer can indicate to the RRC layer that the LTM cell handover has been successfully completed. If configured, the RRC layer can indicate a MAC reset (or partial MAC reset) to the MAC layer.

[0056] For example, when the above conditions are met, if the indicator is configured in the stored configuration (e.g., LTM candidate cell configuration for LTM) corresponding to the target cell (or the cell indicated in the MAC CE or the cell with successful handover), the UE performs RLC reconstruction, which can be accomplished by applying the complete LTM cell configuration. When the conditions are met, the MAC layer can indicate to the RRC layer that the LTM cell handover has been successfully completed. If configured, the RRC layer can indicate RLC reconstruction to the RLC layer.

[0057] For example, when the above conditions are met, if the indicator is configured in the stored configuration (e.g., LTM candidate cell configuration for LTM) corresponding to the target cell (or the cell indicated in the MAC CE or the cell with successful handover), the UE performs PDCP reconstruction, which can be accomplished by applying the complete LTM cell configuration. When the conditions are met, the MAC layer can indicate to the RRC layer that the LTM cell handover has been successfully completed. If configured, the RRC layer can indicate PDCP reconstruction to the PDCP layer.

[0058] For example, when the above conditions are met, if the indicator is configured in the stored configuration (e.g., LTM candidate cell configuration for LTM) corresponding to the target cell (or the cell indicated in the MAC CE or the cell with successful handover), the UE performs PDCP data recovery, which can be accomplished by applying the complete LTM cell configuration. PDCP data recovery can be configured only for PDCP entities associated with AM RLC entities (RLC entities with Acknowledgment Mode (AM) mode). When the conditions are met, the MAC layer can indicate to the RRC layer that the LTM cell handover has been successfully completed. If configured, the RRC layer can indicate PDCP data recovery to the PDCP layer.

[0059] For example, when the above conditions are met, if the indicator is configured in the stored configuration (e.g., LTM candidate cell configuration for LTM) corresponding to the target cell (or the cell indicated in the MAC CE or the cell with successful handover), the UE performs SDU discarding (i.e., PDCP SDU discarding) in the PDCP entity. This can be accomplished by applying the full LTM cell configuration. SDU discarding can be configured only for the PDCP entity of the SRB associated with the AM RLC entity (an RLC entity with an Acknowledgment Mode (AM) mode). When the conditions are met, the MAC layer can indicate to the RRC layer that the LTM cell handover has been successfully completed. If configured, the RRC layer can indicate SDU discarding to the PDCP layer. For the SRB, when an upper layer (e.g., the RRC layer) requests PDCP SDU discarding, the PDCP entity will discard all stored PDCP SDUs and PDCP PDUs. Discarding old RRC messages of the SRB is beneficial to prevent unnecessary (re)transmissions to the target cell. When an LTM cell handover process fails (e.g., the supervisory timer for the LTM cell handover expires), PDCP SDU dropping for the SRB (e.g., SRB1 or SRB3) can be triggered and executed to avoid unnecessary (re)transmission of RRC messages (e.g., RRC reconfiguration completion messages for the target cell to which the UE failed to handover in LTM). When an LTM cell handover process fails (e.g., the supervisory timer for the LTM cell handover expires), RLC reconstruction for the SRB (e.g., SRB1 or SRB3) can be triggered and executed to avoid unnecessary (re)transmission of RRC messages (e.g., RRC reconfiguration completion messages for the target cell to which the UE failed to handover in LTM). When the above conditions are met, the UE can stop the supervisory timer when LTM execution successfully completes.

[0060] In this embodiment, upon receiving a MAC CE indicating LTM cell handover (or LTM cell handover execution), the UE can apply the LTM candidate cell configuration and indicator corresponding to the target cell (or the cell indicated in the MAC CE) to its UE configuration. This approach avoids premature application by the UE and allows for recovery in case of UE failure, simplifying UE implementation. Since the UE cannot know when the network sends the MAC CE indicating LTM cell handover, it can follow this approach to apply the configuration in a timely manner. Receiving the MAC CE indicating LTM cell handover can signify the execution of LTM cell handover.

[0061] For example, upon receiving a MAC CE indicating an LTM cell handover (or LTM cell handover execution), if the indicator is configured in a stored configuration (e.g., LTM candidate cell configuration for LTM) corresponding to the target cell (or the cell indicated in the MAC CE or the successfully handed-over cell), the UE performs a MAC reset (or partial MAC reset), which can be accomplished by applying the full LTM cell configuration. Upon receiving a MAC CE indicating an LTM cell handover (or LTM cell handover execution), the MAC layer can indicate to the RRC layer the successful completion of the LTM cell handover. If configured, the RRC layer can indicate a MAC reset (or partial MAC reset) to the MAC layer.

[0062] For example, upon receiving a MAC CE indicating LTM cell handover (or LTM cell handover execution), if the indicator is configured in a stored configuration (e.g., LTM candidate cell configuration for LTM) corresponding to the target cell (or the cell indicated in the MAC CE or the successfully handed-over cell), the UE performs RLC reconstruction, which can be accomplished by applying the complete LTM cell configuration. Upon receiving a MAC CE indicating LTM cell handover (or LTM cell handover execution), the MAC layer can indicate the successful completion of the LTM cell handover to the RRC layer. If configured, the RRC layer can indicate RLC reconstruction to the RLC layer.

[0063] For example, upon receiving a MAC CE indicating LTM cell handover (or LTM cell handover execution), if the indicator is configured in a stored configuration (e.g., LTM candidate cell configuration for LTM) corresponding to the target cell (or the cell indicated in the MAC CE or the successfully handed-over cell), the UE performs PDCP reconstruction, which can be accomplished by applying the complete LTM cell configuration. Upon receiving a MAC CE indicating LTM cell handover (or LTM cell handover execution), the MAC layer can indicate the successful completion of the LTM cell handover to the RRC layer. If configured, the RRC layer can indicate PDCP reconstruction to the PDCP layer.

[0064] For example, upon receiving a MAC CE indicating LTM cell handover (or LTM cell handover execution), if the indicator is configured in a stored configuration (e.g., LTM candidate cell configuration for LTM) corresponding to the target cell (or the cell indicated in the MAC CE or the successfully handed-over cell), the UE performs PDCP data recovery, which can be accomplished by applying the complete LTM cell configuration. PDCP data recovery can be configured only for PDCP entities associated with AM RLC entities (RLC entities with Acknowledgment Mode (AM) mode). Upon receiving a MAC CE indicating LTM cell handover (or LTM cell handover execution), the MAC layer can indicate the successful completion of the LTM cell handover to the RRC layer. If configured, the RRC layer can indicate PDCP data recovery to the PDCP layer.

[0065] For example, upon receiving a MAC CE indicating LTM cell handover (or LTM cell handover execution), if the indicator is configured in a stored configuration (e.g., LTM candidate cell configuration for LTM) corresponding to the target cell (or the cell indicated in the MAC CE or the successfully handed-over cell), the UE performs SDU discarding (i.e., PDCP SDU discarding) in the PDCP entity. This can be accomplished by applying the full LTM cell configuration. SDU discarding can be configured only for the PDCP entity of the SRB associated with the AM RLC entity (an RLC entity with an Acknowledgment Mode (AM) mode). Upon receiving a MAC CE indicating LTM cell handover (or LTM cell handover execution), the MAC layer can indicate the successful completion of the LTM cell handover to the RRC layer. If configured, the RRC layer can indicate SDU discarding to the PDCP layer. For the SRB, when an upper layer (e.g., the RRC layer) requests PDCP SDU discarding, the PDCP entity will discard all stored PDCP SDUs and PDCP PDUs. Discarding old RRC messages for SRBs to prevent unnecessary (re)transmissions to the target cell is beneficial. When an LTM cell handover process fails (e.g., a supervisory timer for the LTM cell handover expires), PDCP SDUs for SRBs (e.g., SRB1 or SRB3) can be triggered and executed to avoid unnecessary (re)transmissions of RRC messages (e.g., RRC reconfiguration completion messages for the target cell to which the UE failed to hand over in the LTM cell). When an LTM cell handover process fails (e.g., a supervisory timer for the LTM cell handover expires), RLC reconstruction for SRBs (e.g., SRB1 or SRB3) can be triggered and executed to avoid unnecessary (re)transmissions of RRC messages (e.g., RRC reconfiguration completion messages for the target cell to which the UE failed to hand over in the LTM cell).

[0066] In another embodiment, upon receiving a MAC CE indicating LTM cell handover (or LTM cell handover execution), or upon receiving an RRC Reconfiguration message including an indicator (or upon completion of LTM cell candidate configuration, i.e., if the indicator indicates that LTM cell candidate configuration should be applied), the UE can apply the LTM candidate cell configuration and indicator corresponding to the target cell (or the cell indicated in the MAC CE) to the UE configuration. This method can be efficiently executed by the network. For example, the network can send the MAC CE indicating LTM cell handover and the RRC reconfiguration message including the indicator together (e.g., at the same time or in the same MAC PDU) to cause the UE to perform the following actions.

[0067] For example, upon receiving a MAC CE indicating an LTM cell handover (or LTM cell handover execution) or upon receiving an RRCReconfiguration message including an indicator, if the indicator is configured in a stored configuration (e.g., LTM candidate cell configuration for LTM) corresponding to the target cell (or the cell indicated in the MAC CE or the successfully handed-over cell), the UE performs a MAC reset (or partial MAC reset), which can be accomplished by applying the full LTM cell configuration. Upon receiving a MAC CE indicating an LTM cell handover (or LTM cell handover execution), the MAC layer can indicate to the RRC layer the successful completion of the LTM cell handover. If configured, the RRC layer can indicate a MAC reset (or partial MAC reset) to the MAC layer.

[0068] For example, upon receiving an RRCReconfiguration message including an indicator, if the indicator is configured in a stored configuration (e.g., an LTM candidate cell configuration for LTM) corresponding to the target cell (or the cell indicated in the MAC CE or the cell with which a successful handover occurred), the UE performs RLC reconstruction, which can be accomplished by applying the complete LTM cell configuration. Upon receiving an RRCReconfiguration message including an indicator, the MAC layer can indicate to the RRC layer that the LTM cell handover was successfully completed. If configured, the RRC layer can indicate RLC reconstruction to the RLC layer.

[0069] For example, upon receiving an RRCReconfiguration message including an indicator, if the indicator is configured in a stored configuration (e.g., an LTM candidate cell configuration for LTM) corresponding to the target cell (or the cell indicated in the MAC CE or the cell with which a successful handover occurred), the UE performs PDCP reconstruction, which can be accomplished by applying the complete LTM cell configuration. Upon receiving the RRCReconfiguration message including the indicator, the MAC layer can indicate to the RRC layer the successful completion of the LTM cell handover. If configured, the RRC layer can indicate PDCP reconstruction to the PDCP layer.

[0070] For example, upon receiving an RRCReconfiguration message including an indicator, if the indicator is configured in a stored configuration (e.g., an LTM candidate cell configuration for LTM) corresponding to the target cell (or the cell indicated in the MAC CE or the cell with which a successful handover occurred), the UE performs PDCP data recovery, which can be accomplished by applying the complete LTM cell configuration. PDCP data recovery can be configured only for PDCP entities associated with AM RLC entities (RLC entities with AM (Acknowledgement Mode) mode). Upon receiving an RRCReconfiguration message including an indicator, the MAC layer can indicate to the RRC layer that the LTM cell handover was successfully completed. If configured, the RRC layer can indicate PDCP data recovery to the PDCP layer.

[0071] For example, upon receiving an RRCReconfiguration message including an indicator, if the indicator is configured in a stored configuration (e.g., an LTM candidate cell configuration for LTM) corresponding to the target cell (or the cell indicated in the MAC CE or the cell with a successful handover), the UE performs SDU discarding (i.e., PDCP SDU discarding) in the PDCP entity. This can be accomplished by applying the complete LTM cell configuration. SDU discarding can be configured only for the PDCP entity of the SRB associated with the AM RLC entity (an RLC entity with AM (Acknowledgement Mode) mode). Upon receiving an RRCReconfiguration message including an indicator, the MAC layer can indicate to the RRC layer the successful completion of the LTM cell handover. If configured, the RRC layer can indicate SDU discarding to the PDCP layer. For the SRB, when an upper layer (e.g., the RRC layer) requests PDCP SDU discarding, the PDCP entity will discard all stored PDCP SDUs and PDCP PDUs. Discarding old RRC messages of the SRB is beneficial to prevent unnecessary (re)transmissions to the target cell. When an LTM cell handover process fails (e.g., the supervisory timer for the LTM cell handover expires), PDCP SDU dropping for the SRB (e.g., SRB1 or SRB3) can be triggered and executed to avoid unnecessary (re)transmission of RRC messages (e.g., RRC reconfiguration completion messages for the target cell to which the UE failed to handover in LTM). When an LTM cell handover process fails (e.g., the supervisory timer for the LTM cell handover expires), RLC reconstruction for the SRB (e.g., SRB1 or SRB3) can be triggered and executed to avoid unnecessary (re)transmission of RRC messages (e.g., RRC reconfiguration completion messages for the target cell to which the UE failed to handover in LTM).

[0072] It should be noted that the delayed application of this configuration is entirely different from traditional behavior, because in the traditional process, the UE performs a MAC reset / RLC / PDCP reconstruction (if configured) upon receiving an RRCReconfiguration. In the above context, the stored LTM candidate cell configuration can be considered a reference configuration, which can be applied at the proposed specific time.

[0073] - Security is not updated in LTM. In this embodiment, the network determines whether to update security based on the type of mobility (e.g., which cell the UE is instructed to perform a cell handover to). For example, if the candidate cell is within a gNB-DU or gNB-CU, the security configuration for security updates is not included in the LTM candidate cell configuration (RRCReconfiguration). However, if the candidate cell is between gNB-DUs (i.e., inter-gNB-DU mobility), the security configuration for security updates is included in the LTM candidate cell configuration (RRCReconfiguration). When the LTM process (or cell handover) is triggered by a cell handover command via MAC CE, and the conditions for successful LTM cell handover are met, the UE applies and updates the security configuration to the current configuration if it is configured.

[0074] - Subsequent LTMs between LTM candidate cell configurations (i.e., the UE does not release other LTM candidate cell configurations after LTM is triggered) can be performed without RRC reconfiguration.

[0075] LTM supports mobility within and between gNB-DUs, as well as within and between gNB-CUs. LTM also supports inter-frequency mobility, including mobility to cells that are not the current serving cell. The following scenarios are supported: - Changes in the primary cell (PCell) in non-CA scenarios - In the CA scenario, the PCell changes while the secondary cell (SCell) remains unchanged. - In carrier aggregation (CA) scenarios, both PCell and SCell change, including the following situations: a) The target PCell / target SCell is not the current serving cell (CA-to-CA scenario with PCell change). b) The target PCell is the current SCell c) The target SCell is the current PCell.

[0076] - In dual-connectivity scenarios, at least for cases where the PSCell change does not involve the MN (Network Node), i.e., within the SN (Single Network Node). When the UE is configured with dual connectivity (i.e., Secondary Cell Group (SCG) and Primary Cell Group (MCG)), for the SCG (or the LTM procedure for the SCG), the LTM candidate cell configuration for the SCG can be configured via SRB3 in the RRCReconfiguration message; that is, it can be configured after SRB3 is established. For the SCG (or the LTM procedure for the SCG), the LTM candidate cell configuration for the SCG cannot be configured via SRB1. For the MCG (or the LTM procedure for the MCG), the LTM candidate cell configuration for the MCG can be configured via SRB1 in the RRCReconfiguration message; that is, it can be configured after SRB1 is established.

[0077] To support the above scenarios, additional procedures may be required. For example, when considering scenario b) in LTM configuration and LTM procedures (or execution or cell handover) where the target PCell is the current SCell, if the SCell is active (or in an active state), a random access procedure for TA acquisition for LTM candidate cells can be performed on the SCell. However, if the SCell is deactivated (in a deactivated state), a random access procedure for TA acquisition for LTM candidate cells cannot be performed on the SCell because the SCell is off. To support this scenario, one of the following options can be selected to facilitate implementation by the UE and the network.

[0078] Option 1: Since the UE cannot perform a random access procedure (i.e., transmit or execute RACH) on a deactivated SCell, the network does not indicate an LTM cell handover (or random access procedure for TA acquisition) to the deactivated SCell that is the target LTM candidate cell. When the configuration corresponds to the UE's deactivated SCell, the network does not send a first MAC CE (LTM command MAC CE) to the UE including an indicator (or identifier) ​​of the LTM candidate configuration. In other words, the UE does not expect to receive a first MAC CE indicating LTM execution to the UE's deactivated SCell. In this option, "b) the target PCell is the current SCell" can be limited to the case where the target PCell is the currently active SCell, i.e., the network can indicate an LTM cell handover to the active SCell that is the target LTM candidate cell. If the configuration corresponds to the UE's active SCell, the network can send a first MAC CE (LTM command MAC CE) to the UE including an indicator (or identifier) ​​of the LTM candidate configuration.

[0079] Option 2: In this option, when a random access procedure (i.e., sending or executing RACH on RACH) is triggered by a PDCCH command to obtain the TA of the SCell and the SCell is one of the LTM candidate cells configured for the UE, we can allow the UE to perform a random access procedure on a deactivated (or activated) SCell. Except in this case, we do not allow the UE to perform RACH on a deactivated SCell. Therefore, the network can indicate an LTM cell handover to a deactivated (or activated) SCell as the target LTM candidate cell. The network can send the UE a first MAC CE (LTM command MAC CE) including an indicator (or identifier) ​​of the LTM candidate configuration, regardless of the SCell state. To implement this option (i.e., support scenario b), the following procedure is proposed: 1> If SCell is deactivated: 2> Do not send SRS on SCell; 2> CSI not reported for SCell; 2> Do not send on the UL-SCH on the SCell; 2> Do not transmit on the RACH of the SCell, except when the random access procedure (i.e., RACH) is initiated by the PDCCH command of the LTM candidate cell (i.e., SCell) obtained by the TA for the SCell, or when the SCell is configured as one of the LTM candidate cells, or when the SCell is an LTM candidate cell. 2> Do not monitor PDCCH on SCell; 2> Do not monitor PDCCH for SCell; 2> Do not send PUCCH on SCell.

[0080] Option 3: In this option, LTM supports mobility within and between gNB-DUs and gNB-CUs. LTM also supports inter-frequency mobility, including mobility to cells that are not the current serving cell (i.e., PCell, PSCell, or SCell). In other words, the network does not instruct LTM cell handover (or random access procedure for TA acquisition) to the UE's current serving cell (i.e., PCell, PSCell, or SCell) that is a target LTM candidate cell. If the configuration corresponds to the UE's current serving cell, the network does not send a first MAC CE (LTM command MACCE) to the UE that includes an indicator (or identifier) ​​of the LTM candidate configuration. In other words, the UE does not expect to receive a first MAC CE indicating LTM execution to the UE's current serving cell. In another embodiment, the network does not configure an LTM candidate configuration corresponding to the UE's current serving cell to the UE. This configuration restriction can have the same effect as the intent of this option, namely, the network cannot instruct LTM cell handover (or random access procedure for TA acquisition) to the UE's current serving cell (i.e., PCell, PSCell, or SCell) that is a target LTM candidate cell. The network can instruct LTM cell handover (or random access procedure for TA acquisition) to candidate cells other than the UE's current serving cell (i.e., PCell, PSCell, or SCell) that are target LTM candidate cells. If the configuration does not correspond to the UE's current serving cell, the network can send the UE a first MAC CE (LTM Command MACCE) including an indicator (or identifier) ​​of the LTM candidate configuration.

[0081] The following pertains to control plane (CP) processing. Cell handover triggers are transmitted in a MAC CE (i.e., the first MAC CE described later), which contains at least a candidate configuration index and a beam indication.

[0082] During cell handover, the UE can perform either contention-based random access (CBRA) or contention-free random access (CFRA). If the UE does not need to obtain the target cell's TA during cell handover, the UE can also skip the random access procedure (i.e., the no-RACH solution).

[0083] The entire process used for LTM is in Figure 1 As shown in the diagram, subsequent LTM is completed by repeating the early synchronization, LTM execution, and LTM completion steps, without releasing the configuration of other LTM candidate cells after each LTM completion.

[0084] Figure 1 A signaling procedure for LTM according to an embodiment of this disclosure is illustrated.

[0085] Figure 1The details of the steps performed are as follows: Operation 110. The UE sends a MeasurementReport message to the gNB. The gNB decides to use LTM and initiates candidate cell preparation.

[0086] Operation 120. The gNB sends an RRCReconfiguration message to the UE, which includes the LTM candidate cell configuration of one or more candidate cells.

[0087] Operation 130. The UE stores the LTM candidate cell configuration and sends an RRCReconfigurationComplete message to the gNB.

[0088] Operation 140a. The UE can perform DL synchronization with the candidate cell before receiving a cell handover command. DL synchronization with the candidate cell prior to a cell handover command can be supported at least based on the Synchronization Signal Block (SSB).

[0089] Operation 140b. The UE may perform early TA acquisition for a candidate cell requested by the network before receiving a cell handover command. This is done via a random access procedure (i.e., a contention-free random access procedure, CFRA) triggered by a PDCCH command from the source cell, after which the UE sends a preamble to the indicated candidate cell. To minimize data interruption in the source cell due to the CFRA to the candidate cell, the UE does not receive the RAR for TA value acquisition, and the TA value of the candidate cell is indicated in the cell handover command (i.e., the first MAC CE described in Section 4.1). The UE does not maintain a TA timer for the candidate cell and relies on the network implementation to guarantee the validity of the TA.

[0090] At least SSB-based synchronization of candidate cells prior to cell handover commands is required. The necessary mechanisms require further investigation.

[0091] In this embodiment, at least the RACH based on the PDCCH command supports the acquisition of the TA (Timing Advance) of the candidate cell before the LTM cell handover command, where the PDCCH command is triggered only by the source cell. The source cell can trigger a RACH (Random Access Procedure) to the UE in the candidate cell via the PDCCH command to obtain the TA (Timing Advance or Timing Advance Value) of the candidate cell. It only performs preamble transmission and does not expect to receive a RAR (Random Access Response) for ease of network implementation and UE implementation. Specifically, preamble transmission during the RACH (i.e., early RACH) used for TA acquisition can be considered as a successful completion of the RACH. To reduce processing complexity, the UE does not need to calculate the RA-RNTI (Radio Network Temporary Identifier (RNTI) for Random Access Response) before / when sending the preamble, unlike the normal RACH. More specifically, the UE sends a preamble to the candidate cell as instructed by the PDCCH command. The network (or distributed unit (DU) or candidate cell) calculates the timing advance (TA). The source cell / DU can obtain the calculated TA from the candidate cell / DU. By performing a Random Access Procedure (RACH) for TA acquisition (i.e., early RACH), the network can have TA values ​​for candidate cells and know whether these TAs are still valid, for example, by maintaining a network-side timer (i.e., TAT (timeAlignmentTimer)) for each TA value or each candidate cell. In this way, the source cell / DU knows the value and validity of the candidate cell TAs. The source cell / DU needs to know whether the candidate cell TAs are still valid because the source cell / DU needs to determine whether it can initiate a RACH-free solution for LTM cell handover and then determine whether it needs to include beam indication (e.g., TCI status) and TA information in the LTM MAC CE. Therefore, the network can indicate a valid TA or indicate whether a TA is still valid to the UE in the LTM MAC CE. The UE may not need to maintain a TA timer for candidate cells, which simplifies UE implementation. Upon receiving the TA information indicated in the LTM MAC CE, the UE can apply the TA value and start the TA timer for the target LTM candidate cell during LTM execution (i.e., LTM cell handover). If the TAT for the target LTM candidate cell is running (i.e., the TA value is valid) or if no beam fault is detected for the target LTM candidate cell, the UE can perform LTM cell handover without a random access procedure (i.e., using a RACH-free solution to skip the random access procedure). This means that the UE can monitor the PDCCH from the target LTM candidate cell or the UE can use the configured authorization to perform the first UL data transmission to the target cell for RACH-free LTM execution (LTM cell handover).

[0092] Operation 150. The UE performs L1 measurements on the configured candidate cells and sends a low-layer measurement report to the gNB.

[0093] Operation 160. The gNB decides to perform a cell handover to the target cell and sends a MAC CE to trigger the handover, including the candidate configuration index of the target cell. The UE then switches to the configuration of the target cell.

[0094] Operation 170. If cell handover requires the execution of a random access procedure, the UE performs a random access procedure to the target cell.

[0095] Operation 180. The UE completes the LTM cell handover procedure by sending an RRCReconfigurationComplete message to the target cell. If the UE has already performed the RA procedure in Operation 170, the UE considers the LTM execution to be successfully completed when the random access procedure is successfully completed. For LTM without RACH, the UE considers the LTM execution to be successfully completed when it determines that the network has successfully received its first UL data. The UE determines the successful reception of its first UL data by receiving the PDCCH addressing the UE's C-RNTI in the target cell; this PDCCH schedules new transmissions following the first UL data.

[0096] The UE can perform operations 140-180 multiple times for subsequent LTM cell handovers based on the configuration provided in operation 120.

[0097] The following pertains to early downlink synchronization. When configured by the network, a UE in an RRC connection (RRC_CONNECTED) can perform DL synchronization with a cell different from its current serving cell. This can be achieved by pre-activating the TCI state or downlink BWP (bandwidth portion) of the cell that requires early DL synchronization.

[0098] Downlink BWPs can be active or inactive, such as the BWP indicated by firstActiveDownlinkBWP-Id in a cell configuration requiring early DL synchronization (e.g., ServingCellConfig), which can be configured in RRCReconfiguration. TCI states can be activated on downlink BWPs.

[0099] Figure 2 The network-triggered early TCI state (or downlink BWP) activation (early DL synchronization) process according to embodiments of this disclosure is described.

[0100] The operation shown in the image is as follows: Operation 210. The gNB to which cell A belongs provides the UE with a list of TCI states for cell B within the RRCReconfiguration message. The gNB to which cell A belongs can provide a list of TCI states for one or more cells in which the UE can perform an early TCI state activation procedure.

[0101] Operation 220. The UE responds with an RRCReconfigurationComplete message.

[0102] Operation 230. The gNB of cell A sends an Early TCI State Activation MAC CE to the UE to initiate an Early TCI State Activation procedure with cell B. The UE receives the Early TCI State Activation MAC CE from the current serving cell (i.e., cell A (Special Cell (SPcell), PCell, or Primary and Secondary Cell (PSCell))). The Early TCI State Activation MAC CE can also indicate the TCI state of other cells during the TCI State Activation procedure, which may include / indicate a TCI state index or corresponding cell identifier or corresponding downlink BWP identifier for early DL synchronization. To indicate these in the MAC CE, a bitmap can be used to reduce the overhead of the MAC CE. This bitmap can be mapped to configuration information (e.g., cell identifier or BWPID) in ascending order of values, and "1" (or "0") signifies the indication of the corresponding TCI state or cell or downlink BWP.

[0103] Operation 240. (For example, upon receiving an Early TCI State Activation MAC CE indicating the TCI state of a cell (e.g., cell B) and the cell's TCI state), the UE activates the TCI state of cell B indicated in the Early TCI State Activation MAC CE. In other words, the UE activates the TCI state of cell B indicated in the Early TCI State Activation MAC CE on the indicated downlink BWP (e.g., via firstActiveDownlinkBWP-Id for cell B in RRCReconfiguration or via the indication in the MAC CE). In this case, since the TCI states between the network and the UE are well aligned, this will facilitate the early uplink synchronization process.

[0104] In another embodiment, during operation 240, when the UE triggers an LTM cell handover procedure (i.e., upon receiving a first MAC CE (i.e., LTM cell handover command MAC CE)), the UE may activate the TCI state of cell B indicated in the Early TCI State Activation MAC CE to save UE power consumption. Alternatively, when the UE triggers an LTM cell handover procedure (i.e., upon receiving a first MAC CE (i.e., LTM cell handover command MAC CE)), the UE may activate the TCI state of cell B indicated in the Early TCI State Activation MAC CE on the indicated downlink BWP (e.g., via firstActiveDownlinkBWP-Id for cell B in RRCReconfiguration or via the indication in the MAC CE) to save UE power consumption, because PDCCH monitoring on the active BWP results in unnecessary UE power consumption.

[0105] - During the early downlink synchronization process, there are several options regarding how to handle the downlink BWP of cell B: Option 1: Upon receiving an early TCI state activation MACCE indicating the cell (e.g., cell B) and its TCI state, the downlink BWP (e.g., indicated by the firstActiveDownlinkBWP-Id in RRCReconfiguration for the indicated cell (e.g., cell B) or by the MAC CE) is activated or active. The UE activates the downlink BWP and the TCI state of the cell on the downlink BWP during or after the early downlink synchronization process.

[0106] Option 2: Upon receiving the Early TCI State Activation MACCE indicating the cell (e.g., cell B) and the cell's TCI state, the UE determines the cell's TCI state during or after the early downlink synchronization process. When the UE triggers the LTM cell handover procedure (i.e., upon receiving the first MAC CE (i.e., the LTM cell handover command MACCE)), the downlink BWP (e.g., indicated by the firstActiveDownlinkBWP-Id for the indicated cell (e.g., cell B) in the RRCReconfiguration or by the MAC CE) is activated or active, and the UE activates the cell's TCI state on the downlink BWP. The Early TCI State Activation MAC CE and the LTM cell handover command MAC CE can be received together in the same MAC PDU.

[0107] When the SCG is deactivated or activated for SCell or early downlink (or uplink) synchronization, during RRC (reconfiguration) of firstActiveDownlinkBWP-Id and / or firstActiveUplinkBWP-Id for SpCell other than PSCell, the DLBWP and / or UL BWP indicated by firstActiveDownlinkBWP-Id and / or firstActiveUplinkBWP-Id are active without receiving a PDCCH indicating downlink allocation or uplink grant. When the SCG is deactivated, during RRC (reconfiguration) of firstActiveDownlinkBWP-Id for PSCell, the DL BWP is switched to firstActiveDownlinkBWP-Id. The active BWP for the serving cell is indicated by RRC or PDCCH or MAC CE (Early TCI State Activation MAC CE or LTM Cell Handover Command MAC CE). For unpaired spectrum, the DL BWP is paired with the UL BWP, and BWP handover is common to both UL and DL.

[0108] Assume the UE and the gNB belonging to cell B have early DL synchronization. Thus, the gNB belonging to cell A can initiate a cell handover process to cell B by verifying a cell handover command indicating cell B as the target cell. The cell handover command can be, for example, the LTM cell handover command MAC CE.

[0109] When the UE is configured with dual connectivity, this process can be applied to either the MCG or the SCG respectively.

[0110] Early downlink synchronization can be performed before early uplink synchronization because the precise TA value can be measured by the network when the TCI states between the UE and the network are well aligned. That is, the network can trigger early downlink synchronization to the UE first, and then trigger early uplink synchronization to the UE (e.g., after early downlink synchronization is complete). In other embodiments, the network can skip early downlink synchronization and trigger early uplink synchronization to the UE.

[0111] In other embodiments, the early downlink synchronization and LTM cell handover process can be indicated by two MAC CEs together: an early TCI state activation MAC CE and an LTM cell handover command MAC CE. The two MAC CEs can be included in the same MAC PDU, which the network sends to the UE. In this way, the UE activates the indicated TCI state (e.g., on the indicated downlink BWP) and triggers the LTM cell handover process based on the two MAC CEs.

[0112] The following pertains to early uplink synchronization. When configured by the network, a UE in an RRC connection can perform UL synchronization with a cell different from its current serving cell.

[0113] Figure 3 The network-triggered early TA acquisition (early UL synchronization) process according to embodiments of this disclosure is described (i.e., in this application, early uplink synchronization means early TA acquisition process). Figure 3 The operation is shown below: 310. The gNB belonging to cell A provides the TA acquisition configuration to the UE within the RRCReconfiguration message. The TA acquisition configuration includes the RRC configuration information required to send the random access preamble to cell B, enabling the gNB belonging to cell B to calculate the TA value to be used by the UE, for example, in the case of performing an LTM cell handover procedure to cell B. The TA acquisition configuration may include information about one or more cells to which the UE can perform the TA acquisition procedure. The UE receives the TA acquisition configuration from the current serving cell (i.e., cell A, SpCell, PCell, or PSCell) via the RRCReconfiguration message.

[0114] 320. The UE responds with an RRCReconfigurationComplete message.

[0115] 330. The gNB of cell A sends a PDCCH command message to the UE to initiate a TA acquisition procedure with cell B. The PDCCH command may include information required to send the random access preamble to cell B and an indication of whether to perform preamble transmission or preamble retransmission. If no TA is obtained, the gNB of cell A may instruct the retransmission of the preamble used for TA acquisition. The UE receives a PDCCH command from its current serving cell (i.e., cell A, SpCell, PCell, or PSCell) indicating a random access procedure (or preamble (re)transmission) to another cell (e.g., cell B).

[0116] 340. The UE sends a random access preamble to cell B, enabling the gNB to which cell B belongs to calculate the TA value to be used by the UE, for example, if an LTM cell handover process is triggered to cell B.

[0117] There are several options regarding how to handle the uplink BWP of cell B to send a random access preamble to cell B.

[0118] Option 1: For each LTM candidate cell, when the random access procedure on the LTM candidate cell is initiated by a PDCCH command for early uplink synchronization, or when early downlink synchronization is initiated (or completed), the DL BWP and / or UL BWP indicated by firstActiveDownlinkBWP-Id and / or firstActiveUplinkBWP-Id, respectively, are active. That is, during the random access procedure triggered by a PDCCH command (of the serving cell (Spcell, PCell, or PSCell), the UE performs a (re)transmission of the random access preamble to the indicated cell (the LTM candidate cell indicated by the PDCCH command) on the UL BWP for early uplink synchronization (e.g., if a Physical Random Access Channel (PRACH) timing or resource is configured on the UL BWP). Except for the LTM candidate cell indicated by the target configuration ID included in the LTM cell handover command MAC CE, the DL BWP and / or UL BWP on the LTM candidate cell are deactivated upon receiving the LTM cell handover command MAC CE. The DL BWP and / or UL BWP of the LTM candidate cell indicated by the target configuration ID included in the LTM cell handover command MAC CE are active for the serving cell.

[0119] Option 2: For each LTM candidate cell, when the random access procedure on the LTM candidate cell is initiated by a PDCCH command for early uplink synchronization, or when early downlink synchronization is initiated (or completed), the DL BWP and / or UL BWP indicated by firstActiveDownlinkBWP-Id and / or firstActiveUplinkBWP-Id, respectively, are active. That is, during the random access procedure triggered by a PDCCH command (of the serving cell (Spcell, PCell, or PSCell), the UE performs a (re)transmission of the random access preamble on the UL BWP to the indicated cell (the LTM candidate cell indicated by the PDCCH command) for early uplink synchronization (e.g., if PRACH timing or resources are configured on the UL BWP). Upon (re)transmission of the preamble (i.e., when the random access procedure initiated by the PDCCH command for early uplink synchronization is completed), the DL BWP and / or UL BWP on the LTM candidate cell are deactivated.

[0120] For options 1 and 2, the BWP behavior is as follows (when the UE performs early uplink (or downlink) synchronization, in order to save UE power consumption, PDCCH monitoring, sounding reference signal (SRS) transmission, channel state information (CSI) reporting, etc. should not be allowed): 1> If the BWP is activated and used for the active DL of the serving cell, the BWP is not a dormant BWP, and the serving cell is not a PSCell with deactivated SCG, then the UE should: 2> Send on the UL-SCH of the BWP; 2> If PRACH timing is configured, transmission will be performed on the RACH on the BWP; 2> Monitor PDCCH on BWP; 2> If configured, send PUCCH on BWP; 2> Report on CSI regarding BWP; 2> If configured, SRS is sent on the BWP; 2> Receive DL-SCH on BWP; 2> Based on the stored configuration (if any), (re)initialize any suspended configuration uplink authorizations of type 1 on the active BWP, and start them in the symbol according to the rules; 2> If lbt-FailureRecoveryConfig is configured: 3> If lbt-FailureDetectionTimer is running, stop lbt-FailureDetectionTimer; 3> Set LBT_COUNTER to 0; 3> Monitor LBT failure indicators from lower layers.

[0121] 1> If the BWP on the LTM candidate cell is activated for early uplink synchronization, the UE should

[0122] 2> If PRACH timing is configured, transmission will occur on the RACH of the BWP; or

[0123] 2> Do not send on the UL-SCH of the BWP; or

[0124] 2> Do not monitor PDCCH on BWP; or

[0125] 2> Do not monitor PDCCH for BWP (e.g., the UE does not need to monitor PDCCH for BWP via cross-scheduling (i.e., on other BWPs); or

[0126] 2> Do not send PUCCH on BWP; or

[0127] 2> Do not report CSI on BWP; or

[0128] 2> Do not send SRS on BWP; or

[0129] 2> Do not receive DL-SCH on BWP; or

[0130] 2> Clear any configured downlink assignments and any configured uplink grant type 2 associated with the cell (e.g., SCell or LTM candidate cell) (e.g., if one of the SCells is designated as an LTM candidate cell, the configured downlink assignments and configured uplink grant type 2 should be cleared to conserve radio resources); or

[0131] 2> Suspend any configured uplink license type 1 associated with the cell (e.g., SCell or LTM candidate cell) (e.g., if one of the SCells is designated as an LTM candidate cell, the configured uplink license type 1 should be suspended to conserve radio resources); or

[0132] 2> If bwp-InactivityTimer is running in this cell, then stop bwp-InactivityTimer.

[0133] Option 3: For each LTM candidate cell, when the random access procedure on the LTM candidate cell is initiated by a PDCCH command for early uplink synchronization, or when early downlink synchronization is initiated (or completed), the DL BWP and / or UL BWP indicated by firstActiveDownlinkBWP-Id and / or firstActiveUplinkBWP-Id are inactive (i.e., deactivated or remain deactivated). Specifically, during the random access procedure triggered by a PDCCH command (of the serving cell (Spcell, PCell, or PSCell), the UE performs a (re)transmission of the random access preamble to the indicated cell (the LTM candidate cell indicated by the PDCCH command) on the UL BWP (i.e., on the deactivated UL BWP) for early uplink synchronization (e.g., if PRACH timing or resources are configured on the UL BWP). In this way, the UE is allowed to perform a (re)transmission of the preamble to the LTM candidate cell on the deactivated BWP. When the UE successfully completes the LTM cell handover process to the LTM candidate cell indicated by the target configuration ID included in the LTM cell handover command MAC CE, the DL BWP and / or UL BWP on the LTM candidate cell are activated as SpCell (i.e., PCell or PSCell).

[0134] For option 3, the BWP behavior is as follows (when the UE performs early uplink (or downlink) synchronization, in order to save UE power consumption, PDCCH monitoring, SRS transmission, CSI reporting, etc. should not be allowed): 1> If the BWP is activated and used for the active DL of the serving cell, the BWP is not a dormant BWP, and the serving cell is not a PSCell with deactivated SCG, then the UE should: 2> Send on the UL-SCH of the BWP; 2> If PRACH timing is configured, transmission will be performed on the RACH on the BWP; 2> Monitor PDCCH on BWP; 2> If configured, send PUCCH on BWP; 2> Report on CSI regarding BWP; 2> If configured, SRS is sent on the BWP; 2> Receive DL-SCH on BWP; 2> Based on the stored configuration (if any), (re)initialize any suspended configuration uplink authorizations of type 1 on the active BWP, and start them in the symbol according to the rules; 2> If lbt-FailureRecoveryConfig is configured: 3> If lbt-FailureRecoveryConfig is running, stop lbt-FailureDetectionTimer; 3> Set LBT_COUNTER to 0; 3> Monitor LBT failure indicators from lower layers.

[0135] 1> If the BWP is deactivated, or the serving cell is a PSCell with an deactivated SCG, or early uplink synchronization for an LTM candidate cell is initiated, then the UE should

[0136] 2> Do not send on the UL-SCH of the BWP; or

[0137] 2> Except for LTM candidate cells, transmissions are not performed on the RACH of the BWP (i.e., for LTM candidate cells, the UE transmits on the RACH of the BWP, but for the serving cell, the UE should not transmit on the RACH of the BWP).

[0138] 2> Do not monitor PDCCH on BWP; or

[0139] 2> Do not send PUCCH on BWP; or

[0140] 2> Do not report CSI for BWP; or

[0141] 2> Do not send SRS on BWP; or

[0142] 2> Do not receive DL-SCH on BWP; or

[0143] 2> Clear any downlink allocations configured on the BWP and any uplink authorizations configured with authorization type 2; or

[0144] 2> Suspend any configuration authorization type 1 configuration uplink authorization on inactive BWPs; or

[0145] 5. During the TA acquisition process, the gNB belonging to cell A provides the TA value calculated by the gNB belonging to cell B. For example, in the LTM cell handover command MAC CE, this MAC CE initiates an LTM cell handover process to cell B if an LTM cell handover process is triggered to cell B. The UE receives the first MAC CE (i.e., LTM cell handover command MAC CE) from the current serving cell (i.e., cell A, SpCell, PCell, or PSCell), which triggers an LTM cell handover process to another cell (e.g., cell B).

[0146] When the UE is configured with dual connectivity, this process can be applied to either the MCG or the SCG respectively.

[0147] In this application, the receipt of the first MAC CE (i.e., LTM cell handover command MAC CE) signifies the triggering of the LTM cell handover process.

[0148] The following pertains to U-plane processing (user plane processing). In LTM, the network explicitly controls, via RRC signaling, whether the UE performs a partial or full MAC reset, whether to rebuild the RLC, and whether to use PDCP to perform data recovery during cell handover.

[0149] -MAC / RLC Reconstruction / PDCP Data Recovery / PDCP Reconstruction (when configured)

[0150] - RF retuning (e.g., for inter-frequency needs), baseband retuning

[0151] The PDCP data recovery process can be applied to RLC AM bearers used for inter-DU LTM cell handover.

[0152] The following pertains to principles of security protection. These advanced principles should be applied. In this application, security protection means either encryption or integrity protection. Encryption means not only the encryption operation but also the decryption operation, because if data is encrypted at the sender, decryption should be applied to the data at the receiver. Similarly, integrity protection means both integrity verification and integrity protection operations, because if data is integrity protected at the sender, integrity verification should be applied to the data at the receiver.

[0153] AS security includes integrity protection and encryption of RRC signaling (SRB) and user data (DRB).

[0154] RRC processes the configuration of AS security parameters as part of the AS configuration: integrity protection algorithm; encryption algorithm; and two parameters (if integrity protection and / or encryption are enabled for DRB), namely keySetChangeIndicator and nextHopChainingCount, which the UE uses to determine the AS security key during reconfiguration with synchronization (with key change), connection reconstruction, and / or connection restoration.

[0155] The integrity protection algorithm is common to SRB1, SRB2, SRB3 (if configured), SRB4 (if configured), SRBx (if configured), and DRB, all of which have integrity protection configured and share the same keyToUse value. The encryption algorithm is also common to SRB1, SRB2, SRB3 (if configured), SRB4 (if configured), SRBx (if configured), and DRB, all of which have the same keyToUse value configured. Neither integrity protection nor encryption applies to SRB0.

[0156] Note 0: All DRBs associated with the same PDU session have the same enable / disable settings for encryption and the same enable / disable settings for integrity protection.

[0157] RRC integrity protection and encryption are always active together, i.e., active within a single message / process. RRC integrity protection and encryption for SRBs are never deactivated. However, it is possible to switch to the "NULL" encryption algorithm (nea0).

[0158] For SRBx (if configured), RRC integrity protection and encryption can be activated and deactivated based on the configuration or indication of RRC messages (or MAC CE (control element) or PDCP control PDU (protocol data unit)) to reduce the processing burden on the UE. For SRBx (if configured), it is also possible to switch to the "empty" encryption algorithm (nea0) and use the "empty" integrity protection algorithm (nia0).

[0159] The "empty" integrity protection algorithm (nia0) is used only for SRB and for UEs in limited service mode, and when used for SRB, integrity protection is disabled for DRB. The "empty" encryption algorithm is also used when the "empty" integrity protection algorithm is used.

[0160] Note 1: The lower layer discards the RRC message indicating that the integrity protection check has failed and sends an indication to the RRC that the integrity protection verification check has failed.

[0161] The AS uses four different security keys: one for integrity protection of RRC signaling (KRRCint), one for encryption of RRC signaling (KRRCenc), one for integrity protection of user data (KUPint), and one for encryption of user data (KUPenc). All four AS keys are derived from the KgNB key. The KgNB key is based on the KAMF key processed by the upper layer.

[0162] Integrity protection and encryption algorithms can only be changed through synchronous reconfiguration. AS keys (KgNB, KRRCint, KRRCenc, KUPint, and KUPenc) are changed during synchronous reconfiguration (if masterKeyUpdate is included) and during connection reconstruction and connection recovery.

[0163] For each radio bearer, an independent counter (the count (COUNT) used in the PDCP layer) is maintained for each direction. For each radio bearer, the COUNT is used as an input for encryption and integrity protection.

[0164] For a given security key, the same COUNT value is not allowed to be used more than once. The network is responsible for preventing the reuse of COUNT with the same RB identifier and the same key, such as due to large data transfers, the release and establishment of new RBs, and multiple termination point changes for RLC-UM bearers and RLC-AM bearers with SN termination caused by PDCP reconstruction (COUNT reset) with only SN full configuration and the key stream input (i.e., bearer ID, security key) not being updated. To avoid such reuse, the network can, for example, use different RB identifiers for different RB reconstructions, change the AS security key, or switch from RRC connection to RRC idle (RRC_IDLE) / RRC inactive (RRC_INACTIVE) and then back to RRC connection.

[0165] To limit signaling overhead, each message / packet includes a short sequence number (PDCP SN (Sequence Number)). Additionally, an overflow counter mechanism is used: the superframe number (HFN used in the PDCP layer). The HFN needs to be synchronized between the UE and the network.

[0166] For each SRB, the value of the 5-bit BEARER parameter provided by RRC to the lower layer to derive the input for encryption and integrity protection is the value of the corresponding srb-Identity, which has an MSB padded with zeros.

[0167] For UEs equipped with an sk counter, keyToUse indicates whether the UE uses the primary key (KgNB) or the secondary key (S-KeNB or S-KgNB) for a specific DRB. The secondary key is derived from the primary key and sk-counter. The secondary key is updated using a secure key whenever it needs to be refreshed, such as when the MN changes with the KgNB or to avoid COUNT reuse. When the UE is in NR-DC, the network can provide sk-counter to UEs configured with SCG even without using the secondary key (S-KgNB) to allow SRB3 configuration, even when establishing a DRB. When using an MCG bearer terminated by an SN, the network can provide sk-counter to the UE even without SCG configuration.

[0168] The following pertains to the RRC protocol. When an RRC connection has been established, the UE is either in an RRC connected state or an RRC inactive state. If this is not the case, i.e., no RRC connection has been established, the UE is in an RRC idle state. The RRC state can be further characterized as follows: RRC idle: -UE-specific DRX can be configured by the upper layer; - At the lower layer, the UE can be configured with DRX for PTM transmission of MBS broadcast; - UE mobility control based on network configuration; -UE: - Monitor short messages sent via DCI using P-RNTI (see Section 6.5); - Monitor the paging channel used for CN paging with 5G-S-TMSI, unless the UE is acting as an L2 U2N remote UE; - If configured by the upper layer for MBS multicast reception, monitor the paging channel used for CN paging with TMGI; - Perform neighboring cell measurements and cell (re)selection; - Retrieves system information and can send SI requests (if configured); - For UEs configured to record measurements, perform recording of available measurements, as well as location and time; - For UEs configured with idle / inactive measurements, perform idle / inactive measurements; - For the configured UE, perform AI / ML functions (e.g., AI / ML data collection, measurement of AI / ML data, or reporting of AI / ML data). - If configured by the upper layer for MBS broadcast reception, then obtain MCCH change notifications and MBS broadcast control information and data.

[0169] RRC inactive: -UE-specific DRX can be configured by the upper layer or by the RRC layer; - At the lower layer, the UE can be configured with DRX for PTM transmission of MBS broadcast; - UE mobility control based on network configuration; - The UE stores the inactive AS context of the UE; - RAN-based notification areas are configured by the RRC layer; - Transmit unicast data and / or signaling to / from the UE via radio bearers configured for Small Data Transmission (SDT).

[0170] UE: - Monitor short messages sent via downlink control information (DCI) using P-Radio Network Temporary Identifier (RNTI) (see Section 6.5); - During the SDT process, the control channel associated with the shared data channel is monitored to determine whether data has been scheduled for it; - When the SDT procedure is not performed, monitor the paging channels used for CN paging with 5G-S-TMSI and RAN paging with fullI-RNTI, unless the UE is acting as an L2 U2N remote UE; - If configured by the upper layer for MBS multicast reception and the SDT procedure is not performed, monitor the paging channel used for paging with TMGI; - Perform neighboring cell measurements and cell (re)selection; - Perform RAN-based notification area updates periodically and when moving outside the configured RAN-based notification area; - Acquire system information when the SDT process is not in progress, and can send SI requests (if configured); - If the SDT process is not performed, for UEs configured to record measurements, perform recording of available measurements as well as location and time; - If the SDT procedure is not performed, perform the idle / inactive measurement for UEs configured with idle / inactive measurement; - When the SDT process is not performed, AI / ML functions are performed for the configured UE (e.g., collection of AI / ML data or measurement or reporting of AI / ML data). - If configured by the upper layer for MBS broadcast reception, obtain MCCH change notifications and MBS broadcast control information and data; - Send SRS for location.

[0171] RRC connection: -UE stores AS context; - Transmit unicast data to / from the UE; - Transmit MBS multicast data to the UE; - At lower levels, the UE can be configured with UE-specific DRX; - At the lower layer, the UE can be configured with DRX for PTM transmission for MBS broadcast and / or DRX for MBS multicast; - For UEs that support CA, use one or more SCells aggregated with SpCell to increase bandwidth; - For UEs that support DC, use an SCG aggregated with the MCG to increase bandwidth; -Network-controlled mobility within NR, to / from E-UTRA and to UTRA-FDD; - Network-controlled mobility (path handover) between the serving cell and the L2 U2N relay UE, and vice versa.

[0172] -UE: - If configured, monitor short messages sent via DCI using P-RNTI (see Section 6.5). - Monitor the control channel associated with the shared data channel to determine whether data has been scheduled for it; - Provides channel quality and feedback information; - Perform neighboring cell measurements and measurement reports; - For the configured UE, perform AI / ML functions (e.g., AI / ML data collection, measurement of AI / ML data, or reporting of AI / ML data). - Obtain system information; - Perform real-time MDT measurements and report available locations; - If configured by the upper layer for MBS broadcast reception, then obtain MCCH change notifications and MBS broadcast control information and data.

[0173] Figure 4 An overview of the UE RRC state machine and state transitions in NR is shown. According to embodiments of this disclosure, in NR, the UE has only one RRC state at a time.

[0174] Figure 5 The structure of an LTE system according to an embodiment of this disclosure is shown.

[0175] refer to Figure 5The radio access network of the LTE system includes next-generation base stations (also known as evolved Node Bs (hereinafter referred to as eNBs), Node Bs, or base stations) 1a-05, 1a-10, 1a-15, and 1a-20, a Mobility Management Entity (MME) 1a-25, and a Service Gateway (S-GW) 1a-30. User equipment (hereinafter referred to as UEs or terminals) 1a-35 accesses external networks through eNBs 1a-05 to 1a-20 and S-GW 1a-30.

[0176] exist Figure 5 In this context, eNBs 1a-05 to 1a-20 correspond to existing Node Bs in the UMTS system. The eNB connects to UE 1a-35 via a radio channel and performs a more complex role than existing Node Bs. In LTE systems, since all user services related to real-time services via the Internet Protocol (such as Voice over IP (VoIP)) are served through shared channels, a device is needed to perform scheduling by collecting UE state information (such as buffer state, available transmit power state, and channel state), and eNBs 1a-05 to 1a-20 are responsible for this function. Typically, one eNB controls multiple cells. For example, to achieve a transmission rate of 100 Mbps, the LTE system uses Orthogonal Frequency Division Multiplexing (OFDM) as the radio access technology within a 20 MHz bandwidth. Furthermore, the LTE system employs an Adaptive Modulation and Coding (AMC) scheme to determine the modulation scheme and channel coding rate based on the UE's channel state. S-GW 1a-30 is a device that provides data bearers and generates or removes data bearers under the control of MME 125. In addition to managing the mobility of the UE, the MME is also responsible for various control functions and connects to multiple base stations.

[0177] Figure 6 The wireless protocol structure of an LTE system according to an embodiment of this disclosure is shown.

[0178] refer to Figure 6 The radio protocols of the LTE system include Packet Data Convergence Protocol (PDCP) 1b-05 and 1b-40, Radio Link Control (RLC) 1b-10 and 1b-35, and Media Access Control (MAC) 1b-15 and 1b-30 in the UE and eNB, respectively. PDCP 1b-05 and 1b-40 are used to perform operations such as IP header compression / reconstruction. The main functions of PDCP are summarized below: -Header compression and decompression: ROHC only; -Transmission of user data; - For RLC confirmation mode (AM), upper-layer PDUs are delivered sequentially during PDCP reconstruction; - Sequence reordering (for split bearers in DC (RLC AM only): PDCP PDU routing for transmission and PDCP PDU reordering for reception). - For RLC AM, duplicate detection of lower-level service data units (SDUs) during PDCP reconstruction; - For RLC AM, retransmit PDCP SDU during handover, and for separate bearers in DC, retransmit PDCP PDU during PDCP data recovery. - Encryption and decryption; - Timer-based SDU dropping in the uplink.

[0179] Radio Link Control (hereinafter referred to as RLC) 1b-10 and 1b-35 perform ARQ operations by reconfiguring PDCP Protocol Data Units (PDUs) or RLC Service Data Units (SDUs) to an appropriate size. The main functions of RLC are summarized below: -Transmission of upper-layer PDUs; -ARQ function (error correction via ARQ (only for AM data transmission)); - Cascading, segmentation, and reassembly of RLC SDUs (for unacknowledged mode (UM) and AM data transfer only). - Resegmentation of RLC data PDUs (for AM data transmission only); - Reordering of RLC data PDUs (only for UM and AM data transfers); - Duplicate detection (only for UM and AM data transfers); - Protocol error detection (only for AM data transmission); -RLC SDU discard (only for UM and AM data transmission); -RLC reconstruction.

[0180] MAC 1b-15 and 1b-30 connect to multiple RLC layer devices configured in a UE and perform operations such as multiplexing RLC PDUs into MAC PDUs and demultiplexing MAC PDUs into RLC PDUs. The main functions of the MAC are summarized below: - Mapping between logical channels and transport channels; - Multiplexing MAC SDUs belonging to one or different logical channels into a transport block (TB) sent to the physical layer on the transport channel, or demultiplexing MAC SDUs belonging to one or different logical channels from a transport block (TB) received from the physical layer on the transport channel. - Scheduling information report; - Error correction via Hybrid Automatic Repeat Request (HARQ); - Priority processing between logical channels of a UE; - Prioritization is performed among UEs through dynamic scheduling; -MBMS service identifier; -Selection of transmission format; -filling.

[0181] Physical (PHY) layers 1b-20 and 1b-25 can perform the following operations: channel coding and modulation of upper-layer data, forming upper-layer data into OFDM symbols, and transmitting OFDM symbols via a wireless channel; or demodulating OFDM symbols received via a wireless channel, channel decoding OFDM symbols, and transmitting OFDM symbols to the upper layer.

[0182] Figure 7 The diagram illustrates the structure of a next-generation mobile communication system according to an embodiment of the present disclosure.

[0183] refer to Figure 7 The next-generation mobile communication system's radio access network (hereinafter referred to as NR or 5G) includes a new radio node B (hereinafter referred to as NR gNB or NR base station) 1c-10 and a new radio core network (NR CN) 1c-05. User terminals (new radio user equipment, hereinafter referred to as NR UE or UE) 1c-15 access external networks via NR gNB 1c-10 and NR CN 1c-05.

[0184] exist Figure 7In this context, NR gNB 1c-10 corresponds to the evolved Node B (eNB) of the existing LTE system. The NR gNB connects to the NR UE 1c-15 via radio channel 1c-20 and provides superior service compared to the existing Node B. Since all types of user traffic are served through a shared channel, equipment is needed to perform scheduling by collecting UE state information such as buffer state, available transmit power state, and channel state. Furthermore, NR gNB 1c-10 is responsible for this function. Generally, one NR gNB typically controls multiple cells. To achieve ultra-high-speed data transmission compared to existing LTE, the NR gNB can have the maximum available bandwidth or greater, and can additionally employ beamforming technology using Orthogonal Frequency Division Multiplexing (OFDM) as the radio access technology. Furthermore, the NR gNB employs an adaptive modulation and coding (AMC) scheme, which determines the modulation scheme and channel coding rate based on the UE's channel state. NR CN 1c-05 performs functions such as mobility support, bearer configuration, and QoS configuration. The NR CN is a device responsible for various control functions in addition to mobility management for the UE, and it connects to multiple base stations. Furthermore, the next-generation mobile communication system can operate alongside existing LTE systems, and the NR CN connects to the MME 1c-25 via a network interface. The MME connects to the eNB 1c-30, which serves as an existing base station.

[0185] Figure 8 A wireless protocol structure for a next-generation mobile communication system according to an embodiment of this disclosure is shown.

[0186] refer to Figure 8 The next-generation mobile communication system's radio protocols include NR SDAP 1d-01 and 1d-45, NR PDCP 1d-05 and 1d-40, NR RLC 1d-10 and 1d-35, and NR MAC 1d-15 and 1d-30 in the UE and NR base station, respectively.

[0187] The main functions of NR SDAP 1d-01 and 1d-45 may include some of the following: -Transmission of user plane data; - Mapping between QoS flows and data bearers (DRBs) for both downlink (DL) and uplink (UL); - Mark the QoS flow ID in both DL and UL packets; - For UL SDAP PDUs, map reflective QoS flows to DRBs.

[0188] For SDAP layer devices, the UE can be configured via RRC messages to determine whether to use the header of the SDAP layer device (or a new layer device) or its functionality for each PDCP layer device, bearer, or logical channel. When the SDAP header is configured, the NAS reflected QoS reflected configuration 1-bit indicator (NAS reflected QoS) and AS reflected QoS reflected configuration 1-bit indicator (AS reflected QoS) in the SDAP header are used to instruct the UE to enable the updating or reconfiguration of mapping information related to uplink and downlink QoS flows and data bearers. The SDAP header may include QoS flow ID information indicating QoS. QoS information can be used for data processing priority, scheduling information, etc., to support smooth service.

[0189] The main functions of NR PDCP 1d-05 and 1d-40 may include some of the following: - Header compression and decompression (ROHC only); -Transmission of user data; - Ordered delivery of upper-layer PDUs; -Out-of-order delivery of upper-layer PDUs; - PDCP PDU reordering for received data; -Repetitive detection of low-level SDUs; -Retransmission of PDCP SDU; - Encryption and decryption; - Timer-based SDU dropping in the uplink.

[0190] The reordering function of an NR PDCP device refers to the function of reordering PDCP PDUs received from the lower layer in sequence based on the PDCP sequence number (SN), and may include the following functions: sending data to the upper layer in the reordered order, sending data directly to the upper layer without considering the sequence, reordering the sequence and recording lost PDCP PDUs, providing a status report on lost PDCP PDUs to the sending side, and requesting retransmission of lost PDCP PDUs.

[0191] The main functions of NR RLC 1d-10 and 1d-35 may include some of the following: -Transmission of upper-layer PDUs; - Ordered delivery of upper-layer PDUs; -Out-of-order delivery of upper-layer PDUs; - Error correction via ARQ; - Cascading, segmentation, and reassembly of RLC SDUs; - Re-segmentation of RLC data PDUs; - Reordering of RLC data PDUs; -Repeated detection; - Protocol error detection; -RLC SDU discarded; -RLC reconstruction.

[0192] The in-order delivery function of an NR RLC device refers to the function of sending RLC SDUs received from a lower layer to an upper layer in the order of reception, and may include the following functions: if an RLC SDU was initially segmented into multiple RLC SDUs and received, then reassemble and send those multiple RLC SDUs. The in-order delivery function may include the following functions: reordering received RLC PDUs based on the RLC SN or PDCP SN; reordering the sequence and recording lost RLC PDUs; providing a status report to the transmitting side regarding lost RLC PDUs; requesting retransmission of lost RLC PDUs. Alternatively, the in-order delivery function of an NR RLC device may include the following functions: if an RLC SDU is lost, then only RLC SDUs preceding the lost RLC SDU are sent sequentially to the upper layer; or if a timer expires, despite the existence of lost RLC SDUs, all RLC SDUs received before the timer started are sent sequentially to the upper layer; or if a scheduled timer expires, despite the existence of lost RLC SDUs, all RLC SDUs received to date are sent sequentially to the upper layer. Furthermore, RLC PDUs can be processed in the order they are received (according to arrival order, regardless of number or sequence number) and sent to the PDCP device out of order. In-order delivery functionality can include the following: receiving segments stored in a buffer or segments to be received later; reconfiguring segments into a complete RLC PDU; processing the RLC PDU; and sending the RLC PDU to the PDCP device. The NRRLC layer may not include concatenation functionality, and concatenation functionality can be performed by the NR MAC layer or replaced by multiplexing functions of the NR MAC layer.

[0193] The out-of-order delivery function of an NR RLC device refers to the function of sending RLC SDUs received from the lower layer directly to the upper layer without regard to their order, and may include the following functions: if an RLC SDU is initially segmented into multiple RLC SDUs and received, reassemble the multiple RLC SDUs and send them; and store the RLC SN or PDCP SN of the received RLC PDUs, reorder the sequence and record the lost RLC PDUs.

[0194] NR MAC 1d-15 and 1d-30 can connect to multiple NR RLC layer devices configured in a single UE, and the main functions of NR MAC can include some of the following: - Mapping between logical channels and transport channels; - Multiplexing / demultiplexing of MAC SDUs; - Scheduling information report; - Error correction via HARQ; - Priority processing between logical channels of a UE; - Prioritization is performed among UEs through dynamic scheduling; -MBMS service identifier; -Selection of transmission format; -filling.

[0195] NR PHY layers 1d-20 and 1d-25 can perform the following operations: channel coding and modulation of upper-layer data, forming upper-layer data into OFDM symbols, delivering OFDM symbols via a radio channel; or demodulating and channel decoding OFDM symbols received via a radio channel, and transmitting OFDM symbols to the upper layer.

[0196] Figure 9 A message stream illustrating a successful RRC reconfiguration is shown according to an embodiment of this disclosure.

[0197] Figure 10 A message stream illustrating an RRC reconfiguration failure is shown according to an embodiment of this disclosure.

[0198] The following pertains to the RRC process. (See reference) Figure 9 and 10 .

[0199] The purpose of this process is to modify RRC connections (e.g., establish / modify / release RB / BH RLC channels / Uu relay RLC channels / PC5 relay RLC channels), perform reconfiguration with synchronization, establish / modify / release measurements, add / modify / release SCells and cell groups, add / modify / release conditional handover configurations, add / modify / release conditional PSCell change or conditional PSCell add configurations, and add / modify / LTM candidate cells. As part of this process, NAS-specific information can be transmitted from the network to the UE.

[0200] RRC reconfiguration for performing synchronous reconfiguration includes, but is not limited to, the following: - Features synchronized reconfiguration and security key refresh, involving RA, MAC reset, security refresh, and RLC and PDCP reconstruction triggered by explicit L2 indicators for Pcell / PSCell; - Features synchronous reconfiguration but no security key refresh, involving RA and MAC resets of Pcell / PSCell and reconstruction of RLC and PDCP triggered by explicit L2 indicators (for AM DRB or AM MRB).

[0201] - Synchronous reconfiguration and security key refresh for DAPS involve the establishment of the target Pcell's RA, the target MAC, and...

[0202] - For non-DAPS bearers: Secure refresh and RLC and PDCP reconstruction triggered by explicit L2 indicators; - For DAPS bearers: Establishment of RLC, security refresh, and reconfiguration of PDCP for the target Pcell to add encryption, integrity protection, and ROHC functionality to the target Pcell; - For SRB: Safe refresh of the target Pcell and reconstruction of RLC and PDCP; - For DAPS, synchronous reconfiguration without security key refresh involves the establishment of the target Pcell's RA, target MAC, and... - For non-DAPS bearers: RLC reconstruction and PDCP data recovery triggered by explicit L2 indicators (for AM DRB or AM MRB).

[0203] - For DAPS bearers: Establishment of RLC and reconfiguration of PDCP for the target Pcell to add encryption, integrity protection and ROHC functions to the target Pcell; - For SRB: Establishment of RLC and PDCP for the target Pcell.

[0204] - For direct-to-indirect path switching with synchronous reconfiguration, not involving the target-side RA, but involving the reconstruction of PDCP / PDCP data recovery (for AM DRB) triggered by explicit L2 indicators.

[0205] In (NG)EN-DC and NR-DC, SRB3 can be used for measurement configuration and reporting, for UE-assisted (re)configuration and reporting for power saving, for IP address (re)configuration and reporting of IAB nodes, for (re)configuration of MAC, RLC, BAP, physical layer and RLF timers and SCG configuration constants, and for reconfiguring the PDCP of the DRB associated with the S-KgNB or SRB3, and for reconfiguring the SDAP of the DRB associated with the S-KgNB in ​​NGEN-DC and NR-DC, and for adding / modifying / releasing conditional PSCell change configurations (provided that (re)configuration does not require any MN participation), and for sending RRC messages between the MN and UE during fast MCG link recovery. In (NG)EN-DC and NR-DC, the RRCReconfiguration received via SRB3 includes only measConfig, radioBearerConfig, conditionalReconfiguration, bap-Config, iab-IP-AddressConfigurationList, otherConfig, and / or secondaryCellGroup, unless the RRCReconfiguration is received within DLInformationTransferMRDC.

[0206] Initiate

[0207] The network can initiate an RRC reconfiguration procedure for a UE in an RRC connection. The network applies this procedure as follows: -RB (except SRB1, which is established during RRC connection establishment) establishment is performed only when AS security has been activated; - The establishment of the BH RLC channel for IAB is only performed when AS security has been activated; - The establishment of Uu trunk RLC channels and PC5 trunk RLC channels (excluding SL-RLC0 and SL-RLC1) for L2 U2N trunk UEs is performed only when AS security is activated, and the establishment of PC5 trunk RLC channels (excluding SL-RLC0 and SL-RLC1) for L2 U2N remote UEs is performed only when AS security is activated. - The addition of secondary cell groups and SCells is only performed when AS security has been activated; - ReconfigurationWithSync is included in secondaryCellGroup only if at least one RLC bearer or BH RLC channel is established in SCG; - ReconfigurationWithSync is included in masterCellGroup only if AS security has been activated and SRB2 and at least one DRB or multicast MRB or SRB2 (for IAB) have been established and not suspended; - ReconfigurationWithSync for CPC is included only if at least one RLC bearer is established in the SCG; -Conditional reconfiguration for CHO or CPA is included only if AS security has been activated and SRB2 and at least one DRB or multicast MRB or SRB2 (for IAB) have been established and not suspended.

[0208] - The ltm-CandidateConfig (LTM candidate cell configuration) for LTM is included only if AS security has been activated and SRB2 and at least one DRB have been established and not suspended.

[0209] UE receives RRCReconfiguration

[0210] When an RRCReconfiguration is received, or when a conditional reconfiguration (CHO, CPA, or CPC) is performed, the UE should perform the following actions: For LTM cell handover, the following describes how to generate the RRCReconfigurationComplete message.

[0211] Option 1. Generate an RRCReconfigurationComplete message upon receiving an LTM-triggered MAC CE (or LTM cell handover execution), and then send the RRCReconfigurationComplete message to the target cell during the LTM cell handover process (e.g., via message 3 if a random access procedure is performed; or via uplink data transmission if the random access procedure is skipped (or not performed, i.e., no RACH)). Option 1 simplifies UE implementation because the UE cannot know in advance which cell it will perform the LTM cell handover to.

[0212] Note: To reduce the processing delay for generating RRCReconfigurationComplete, the UE can generate an RRCReconfigurationComplete message in advance for each LTM candidate cell configuration when it receives an RRCReconfiguration message that includes ltm-CandidateConfig (LTM candidate cell configuration). That is, for the LTM cell handover process, the UE can decide to send one of the RRCReconfigurationComplete messages based on the LTM-triggered MAC CE received in the MAC entity.

[0213] 1> If the LTM cell handover is triggered from a lower layer (e.g., by receiving an LTM-triggered MAC CE in the MAC entity, or by LTM cell handover execution), or if the target LTM candidate cell configuration is applied due to LTM candidate cell execution (in another embodiment, a second RRCReconfigurationComplete message may be generated when the LTM cell handover (LTM execution) completes successfully): 2> Set the content of the RRCReconfigurationComplete message as follows: 3> Includes LTM candidate cell configuration / information (e.g., cell identifier or UE identifier or configuration index or configuration identifier) ​​of the target cell indicated from a lower layer (e.g., as indicated by the LTM trigger MAC CE).

[0214] Note: If this process is initiated to generate a complete LTM candidate cell configuration, even if the UE processes both the LTM reference configuration and the LTM candidate cell configuration, the UE should only generate one RRCReconfigurationComplete message. The RRCReconfigurationComplete message includes the contents of the target cell indicated by the LTM-triggered MAC CE.

[0215] 1> If the RRCReconfiguration message includes ltm-CandidateConfig (LTM candidate cell configuration): 2> Then execute the LTM configuration process specified in 3.3.1.3; 1> If the RRCReconfiguration message does not include ltm-candidateConfig (LTM candidate cell configuration), then set the content of the RRCReconfigurationComplete message as follows: Note: If this process is initiated to generate a complete LTM candidate cell configuration, even if the UE processes both the LTM reference configuration and the LTM candidate cell configuration, the UE should only generate one RRCReconfigurationComplete message. The RRCReconfigurationComplete message includes the contents of the target cell indicated by the LTM-triggered MAC CE.

[0216] 2> If RRCReconfiguration includes a masterCellGroup containing reportUplinkTxDirectCurrent: 3> Includes uplinkTxDirectCurrentList for each MCG serving cell with UL; 3> Include uplinkDirectCurrentBWP-SUL (if any) for each MCG serving cell configured with a SUL carrier in the uplinkTxDirectCurrentList; 2> If RRCReconfiguration includes a masterCellGroup containing reportUplinkTxDirectCurrentTwoCarrier: 3> Then the uplinkTxDirectCurrentTwoCarrierList includes a list of uplink Tx DC locations configured in the MCG for in-band uplink carrier aggregation; 2> If RRCReconfiguration includes a masterCellGroup containing reportUplinkTxDirectCurrentMoreCarrier: 3> Then the uplinkTxDirectCurrentMoreCarrierList includes a list of uplink Tx DC locations configured in the MCG for in-band uplink carrier aggregation; 2> If RRCReconfiguration includes a secondaryCellGroup containing reportUplinkTxDirectCurrent: 3> Includes a list of uplinkTxDirectCurrentList for each SCG serving cell with UL; 3> Include uplinkDirectCurrentBWP-SUL (if any) for each SCG serving cell configured with a SUL carrier in the uplinkTxDirectCurrentList; 2> If RRCReconfiguration includes a secondaryCellGroup containing reportUplinkTxDirectCurrentTwoCarrier: 3> Then the uplinkTxDirectCurrentTwoCarrierList includes a list of uplink Tx DC locations configured in the SCG for in-band uplink carrier aggregation; 2> If RRCReconfiguration includes a secondaryCellGroup containing reportUplinkTxDirectCurrentMoreCarrier: 3> Then the uplinkTxDirectCurrentMoreCarrierList includes a list of uplink Tx DC locations configured in the SCG for in-band uplink carrier aggregation; Note 0b: The UE does not expect to receive either reportUplinkTxDirectCurrentTwoCarrier or reportUplinkTxDirectCurrentMoreCarrier in either the masterCellGroup or the secondaryCellGroup. The network configures at most one of reportUplinkTxDirectCurrent, reportUplinkTxDirectCurrentTwoCarrier, or reportUplinkTxDirectCurrentMoreCarrier in a single RRC message.

[0217] 2> If the RRCReconfiguration message includes a SecondaryCellGroupConfig with an mrdc-SecondaryCellGroup set to eutra-SCG: 3> According to TS 36.331

[10] Section 5.3.5.3, the Eutra-SCG-Response includes the E-UTRA RRCConnectionReconfigurationComplete message; 2> If the RRCReconfiguration message includes an mrdc-SecondaryCellGroupConfig with an mrdc-SecondaryCellGroup set to nr-SCG: 3> Then the nr-SCG-Response will include the SCG RRCReconfigurationComplete message; 3> If an RRCReconfiguration message was applied due to conditional reconfiguration execution, and the RRCReconfiguration message is not included in the masterCellGroup under the reconfigurationWithSync message: 4> Then selectedCondRRCReconfig includes the condReconfigId of the selected cell for conditional reconfiguration; 2> If RRCReconfiguration includes reconfigurationWithSync in MCG's spCellConfig: 3> If the UE has a recorded measurement available for NR, and if the RPLMN is included in the plmn-IdentityLis stored in the VarLogMeasReport: 4> Then the RRCReconfigurationComplete message will include logMeasAvailable; 4> If the Bluetooth measurement results are included in the measurements that the UE has recorded and that can be used for NR: 5> Then the RRCReconfigurationComplete message includes logMeasAvailableBT; 4> If the WLAN measurement results are included in the measurements that the UE has recorded and that can be used for NR: 5> Then the RRCReconfigurationComplete message includes logMeasAvailableWLAN; 3> If sigLoggedMeasType from VarLogMeasReport is included: 4> If the T330 timer is running and the recorded measurement configuration is used for NR: 5> Then set sigLogMeasConfigAvailable to true in the RRCReconfigurationComplete message; 4> Otherwise: 5> If the UE has measurements that can be used for NR recording: 6> Then set sigLogMeasConfigAvailable to false in the RRCReconfigurationComplete message; 3> If the UE has available connection establishment failure or connection recovery failure information in VarConnEstFailReport or VarConnEstFailReportList, and if RPLMN equals the plmn-Identity in at least one of the entries stored in VarConnEstFailReport or VarConnEstFailReportList: 4> The RRCReconfigurationComplete message will include connEstFailInfoAvailable; 3> If the UE has available radio link failure or handover failure information in the VarRLF-Report, and if the RPLMN is included in the plmn-IdentityList stored in the VarRLF-Report; or 3> If the UE has available radio link failure or handover failure information in the VarRLF-Report of TS 36.331

[10] , and if the UE is able to make cross-RAT RLF reports, and if the RPLMN is included in the plmn-IdentityList stored in the VarRLF-Report of TS 36.331

[10] : 4> Then the RRCReconfigurationComplete message will include rlf-InfoAvailable; 3> If the UE configured successHO-Config when connecting to the source Pcell; and 3> If the applied RRCReconfiguration is not due to conditional reconfiguration performed during cell selection at the timer T311 runtime, as defined in 5.3.7.3: 4> Upon successful completion of the random access procedure triggered by reconfigurationWithSync in spCellConfig for MCG, the actions for determining the successful handover report shall be performed in accordance with the provisions of Section 5.7.10.6; 3> If the UE has available successful handover information in the VarSuccessHO-Report, and if the RPLMN is included in the plmn-IdentityList stored in the VarSuccessHO-Report: 4> Include successHO-InfoAvailable in the RRCReconfigurationComplete message; 2> If the RRCReconfiguration message is received via SRB1, but not in mrdc-SecondaryCellGroup, E-UTRA RRCConnectionReconfiguration, or E-UTRARRCConnectionResume: 3> If the UE is configured to provide measurement gap requirement information for the NR target frequency band: 4> If the RRCReconfiguration message includes needForGapsConfigNR; or 4> If the NeedForGapsInfoNR information has changed since the UE last reported this information: 5> Include NeedForGapsInfoNR and set its contents as follows: 6> Includes intraFreq-needForGap, and sets gap requirement information for co-frequency measurements for each NR serving cell; 6> If requestedTargetBandFilterNR is configured: 7> For each supported NR band that is also included in requestedTargetBandFilterNR, include an entry in interFreq-needForGap and set the gap requirement information for that band; 6> Otherwise: 7> Include entries in interFreq-needForGap and set the corresponding gap requirement information for each supported NR band; 3> If the UE is configured to provide NR target band measurement gap and NCSG requirement information: 4> If the RRCReconfiguration message includes needForGapNCSG-ConfigNR; or 4> If the needForGapNCSG-InfoNR information has changed since the UE last reported this information: 5> Include NeedForGapNCSG-InfoNR and set its contents as follows: 6> Includes intraFreq-needForNCSG, and sets the interval for co-frequency measurements and NCSG requirement information for each NR serving cell; 6> If requestedTargetBandFilterNCSG-NR is configured: 7> For each supported NR band included in requestedTargetBandFilterNCSG-NR, include an entry in interFreq-needForNCSG and set the NCSG requirement information for that band; 6> Otherwise: 7> Include entries for each supported NR band in interFreq-needForNCSG and set the corresponding NCSG requirement information; 3> If the UE is configured to provide EUTRA target band measurement gap and NCSG requirement information: 4> If the RRCReconfiguration message includes needForGapNCSG-ConfigEUTRA; or 4> If the needForGapNCSG-InfoEUTRA information has changed since the UE last reported this information: 5> This includes NeedForGapNCSG-InfoEUTRA, and its contents are set as follows: 6> If requestedTargetBandFilterNCSG-EUTRA is configured, for each supported E-UTRA band included in requestedTargetBandFilterNCSG-EUTRA, an entry is included in needForNCSG-EUTRA and NCSG requirement information is set for that band; otherwise, an entry is included in needForNCSG-EUTRA for each supported E-UTRA band and the corresponding NCSG requirement information is set. 2> If the process is initiated to generate a complete LTM candidate cell configuration: 3> Then the process ends.

[0218] Option 2. Upon receiving an RRCReconfiguration, generate an RRCReconfigurationComplete message corresponding to the RRCReconfiguration and send it to the source cell (the serving cell or the current cell from which the UE received the RRCReconfiguration). Upon receiving an LTM-triggered MAC CE (or an LTM cell handover execution), generate another RRCReconfigurationComplete message and then send it to the target cell during the LTM cell handover process (e.g., via message 3 if a random access procedure is performed; or via uplink data transmission if the random access procedure is skipped (or not performed, i.e., no RACH)). Option 2 allows the network to know about the successful delivery of the RRCReconfiguration and simplifies implementation for the UE, as the UE cannot know in advance which cell it will perform the LTM cell handover to.

[0219] Note: To reduce the processing delay for generating RRCReconfigurationComplete, the UE can generate an RRCReconfigurationComplete message in advance for each LTM candidate cell configuration when it receives an RRCReconfiguration message that includes ltm-CandidateConfig (LTM candidate cell configuration). That is, for the LTM cell handover process, the UE can decide to send one of the RRCReconfigurationComplete messages based on the LTM-triggered MAC CE received in the MAC entity.

[0220] 1> If the LTM cell handover is triggered from a lower layer (e.g., by receiving an LTM-triggered MAC CE or LTM cell handover execution in the MAC entity), or if the target LTM candidate cell configuration is applied due to LTM candidate cell execution (in another embodiment, a second RRCReconfigurationComplete message may be generated when the LTM cell handover (LTM execution) completes successfully): 2> Set the content of the RRCReconfigurationComplete message as follows: 3> Includes LTM candidate cell configuration / information (e.g., cell identifier or UE identifier or configuration index or configuration identifier) ​​of the target cell indicated from a lower layer (e.g., as indicated by the LTM trigger MAC CE).

[0221] Note: If this process is initiated to generate a complete LTM candidate cell configuration, even if the UE processes both the LTM reference configuration and the LTM candidate cell configuration, the UE should only generate one RRCReconfigurationComplete message. The RRCReconfigurationComplete message includes the contents of the target cell indicated by the LTM-triggered MAC CE.

[0222] 1> If the RRCReconfiguration message includes ltm-CandidateConfig (LTM candidate cell configuration): 2> Perform the LTM configuration process specified in 3.3.1.3; 2> Configure the content of the RRCReconfigurationComplete message as follows: Note: If this process is initiated to generate a complete LTM candidate cell configuration, even if the UE processes both the LTM reference configuration and the LTM candidate cell configuration, the UE should only generate one RRCReconfigurationComplete message. The RRCReconfigurationComplete message includes the contents of the target cell indicated by the LTM-triggered MAC CE.

[0223] 2> If RRCReconfiguration includes a masterCellGroup containing reportUplinkTxDirectCurrent: 3> Includes uplinkTxDirectCurrentList for each MCG serving cell with UL; 3> Include uplinkDirectCurrentBWP-SUL (if any) for each MCG serving cell configured with a SUL carrier in the uplinkTxDirectCurrentList; 2> If RRCReconfiguration includes a masterCellGroup containing reportUplinkTxDirectCurrentTwoCarrier: 3> Then the uplinkTxDirectCurrentTwoCarrierList includes a list of uplink Tx DC locations configured in the MCG for in-band uplink carrier aggregation; 2> If RRCReconfiguration includes a masterCellGroup containing reportUplinkTxDirectCurrentMoreCarrier: 3> Then the uplinkTxDirectCurrentMoreCarrierList includes a list of uplink Tx DC locations configured in the MCG for in-band uplink carrier aggregation; 2> If RRCReconfiguration includes a secondaryCellGroup containing reportUplinkTxDirectCurrent: 3> Includes a list of uplinkTxDirectCurrentList for each SCG serving cell with UL; 3> Include uplinkDirectCurrentBWP-SUL (if any) for each SCG serving cell configured with a SUL carrier in the uplinkTxDirectCurrentList; 2> If RRCReconfiguration includes a secondaryCellGroup containing reportUplinkTxDirectCurrentTwoCarrier: 3> Then the uplinkTxDirectCurrentTwoCarrierList includes a list of uplink Tx DC locations configured in the SCG for in-band uplink carrier aggregation; 2> If RRCReconfiguration includes a secondaryCellGroup containing reportUplinkTxDirectCurrentMoreCarrier: 3> Then the uplinkTxDirectCurrentMoreCarrierList includes a list of uplink Tx DC locations configured in the SCG for in-band uplink carrier aggregation; Note 0b: The UE does not expect to receive either reportUplinkTxDirectCurrentTwoCarrier or reportUplinkTxDirectCurrentMoreCarrier in either the masterCellGroup or the secondaryCellGroup. The network configures at most one of reportUplinkTxDirectCurrent, reportUplinkTxDirectCurrentTwoCarrier, or reportUplinkTxDirectCurrentMoreCarrier in a single RRC message.

[0224] 2> If the RRCReconfiguration message includes a SecondaryCellGroupConfig with an mrdc-SecondaryCellGroup set to eutra-SCG: 3> According to TS 36.331

[10] Section 5.3.5.3, the Eutra-SCG-Response includes the E-UTRA RRCConnectionReconfigurationComplete message; 2> If the RRCReconfiguration message includes an mrdc-SecondaryCellGroupConfig with an mrdc-SecondaryCellGroup set to nr-SCG: 3> Then the nr-SCG-Response will include the SCG RRCReconfigurationComplete message; 3> If an RRCReconfiguration message was applied due to conditional reconfiguration execution, and the RRCReconfiguration message is not included in the masterCellGroup under the reconfigurationWithSync message: 4> Then selectedCondRRCReconfig includes the condReconfigId of the selected cell for conditional reconfiguration; 2> If RRCReconfiguration includes reconfigurationWithSync in MCG's spCellConfig: 3> If the UE has a recorded measurement available for NR, and if the RPLMN is included in the plmn-IdentityLis stored in the VarLogMeasReport: 4> Then the RRCReconfigurationComplete message will include logMeasAvailable; 4> If the Bluetooth measurement results are included in the measurements that the UE has recorded and that can be used for NR: 5> Then the RRCReconfigurationComplete message includes logMeasAvailableBT; 4> If the WLAN measurement results are included in the measurements that the UE has recorded and that can be used for NR: 5> Then the RRCReconfigurationComplete message includes logMeasAvailableWLAN; 3> If sigLoggedMeasType from VarLogMeasReport is included: 4> If the T330 timer is running and the recorded measurement configuration is used for NR: 5> Then set sigLogMeasConfigAvailable to true in the RRCReconfigurationComplete message; 4> Otherwise: 5> If the UE has measurements that can be used for NR recording: 6> Then set sigLogMeasConfigAvailable to false in the RRCReconfigurationComplete message; 3> If the UE has available connection establishment failure or connection recovery failure information in VarConnEstFailReport or VarConnEstFailReportList, and if RPLMN equals the plmn-Identity in at least one of the entries stored in VarConnEstFailReport or VarConnEstFailReportList: 4> The RRCReconfigurationComplete message will include connEstFailInfoAvailable; 3> If the UE has available radio link failure or handover failure information in the VarRLF-Report, and if the RPLMN is included in the plmn-IdentityList stored in the VarRLF-Report; or 3> If the UE has available radio link failure or handover failure information in the VarRLF-Report of TS 36.331

[10] , and if the UE is able to make cross-RAT RLF reports, and if the RPLMN is included in the plmn-IdentityList stored in the VarRLF-Report of TS 36.331

[10] : 4> Then the RRCReconfigurationComplete message will include rlf-InfoAvailable; 3> If the UE configured successHO-Config when connecting to the source Pcell; and 3> If the applied RRCReconfiguration is not due to conditional reconfiguration performed during cell selection at the timer T311 runtime, as defined in 5.3.7.3: 4> Upon successful completion of the random access procedure triggered by reconfigurationWithSync in spCellConfig for MCG, the actions for determining the successful handover report shall be performed in accordance with the provisions of Section 5.7.10.6; 3> If the UE has available successful handover information in the VarSuccessHO-Report, and if the RPLMN is included in the plmn-IdentityList stored in the VarSuccessHO-Report: 4> Include successHO-InfoAvailable in the RRCReconfigurationComplete message; 2> If the RRCReconfiguration message is received via SRB1, but not in mrdc-SecondaryCellGroup, E-UTRA RRCConnectionReconfiguration, or E-UTRARRCConnectionResume: 3> If the UE is configured to provide measurement gap requirement information for the NR target frequency band: 4> If the RRCReconfiguration message includes needForGapsConfigNR; or 4> If the NeedForGapsInfoNR information has changed since the UE last reported this information: 5> Include NeedForGapsInfoNR and set its contents as follows: 6> Includes intraFreq-needForGap, and sets gap requirement information for co-frequency measurements for each NR serving cell; 6> If requestedTargetBandFilterNR is configured: 7> For each supported NR band that is also included in requestedTargetBandFilterNR, include an entry in interFreq-needForGap and set the gap requirement information for that band; 6> Otherwise: 7> Include entries in interFreq-needForGap and set the corresponding gap requirement information for each supported NR band; 3> If the UE is configured to provide NR target band measurement gap and NCSG requirement information: 4> If the RRCReconfiguration message includes needForGapNCSG-ConfigNR; or 4> If the needForGapNCSG-InfoNR information has changed since the UE last reported this information: 5> Include NeedForGapNCSG-InfoNR and set its contents as follows: 6> Includes intraFreq-needForNCSG, and sets the interval for co-frequency measurements and NCSG requirement information for each NR serving cell; 6> If requestedTargetBandFilterNCSG-NR is configured: 7> For each supported NR band included in requestedTargetBandFilterNCSG-NR, include an entry in interFreq-needForNCSG and set the NCSG requirement information for that band; 6> Otherwise: 7> Include entries for each supported NR band in interFreq-needForNCSG and set the corresponding NCSG requirement information; 3> If the UE is configured to provide EUTRA target band measurement gap and NCSG requirement information: 4> If the RRCReconfiguration message includes needForGapNCSG-ConfigEUTRA; or 4> If the needForGapNCSG-InfoEUTRA information has changed since the UE last reported this information: 5> This includes NeedForGapNCSG-InfoEUTRA, and its contents are set as follows: 6> If requestedTargetBandFilterNCSG-EUTRA is configured, for each supported E-UTRA band included in requestedTargetBandFilterNCSG-EUTRA, an entry is included in needForNCSG-EUTRA and NCSG requirement information is set for that band; otherwise, an entry is included in needForNCSG-EUTRA for each supported E-UTRA band and the corresponding NCSG requirement information is set. 2> If the process is initiated to generate a complete LTM candidate cell configuration: 3> Then the process ends.

[0225] Option 3. Upon receiving an RRCReconfiguration, generate an RRCReconfigurationComplete corresponding to the RRCReconfiguration and send it to the source cell (the serving cell or the current cell from which the UE received the RRCReconfiguration). If a random access procedure is triggered upon receiving an LTM-triggered MAC CE (or LTM cell handover execution), an RRCReconfigurationComplete message is generated and sent to the target LTM cell (e.g., via message 3). However, if no random access procedure is triggered or executed upon receiving an LTM-triggered MAC CE (or LTM cell handover execution) (i.e., skipped (in the no-RACH case)), no RRCReconfigurationComplete message is generated and not sent to the target LTM cell. The UE can perform uplink data transmission (i.e., only user plane data) without an RRCReconfigurationComplete message. Option 3 reduces signaling overhead on top of the advantages of Option 2.

[0226] To reduce the processing delay for generating RRCReconfigurationComplete, the UE can generate an RRCReconfigurationComplete message in advance for each LTM candidate cell configuration when it receives an RRCReconfiguration message that includes ltm-CandidateConfig (LTM candidate cell configuration). That is, for the LTM cell handover process, the UE can decide to send one of the RRCReconfigurationComplete messages based on the LTM-triggered MAC CE received in the MAC entity.

[0227] 3> If the LTM cell handover is triggered from a lower layer (e.g., by receiving an LTM-triggered MAC CE or LTM cell handover execution in the MAC entity), or if the target LTM candidate cell configuration is applied due to LTM candidate cell execution, or a random access procedure is triggered (or if the lower layer (i.e., the MAC layer) indicates that the LTM cell execution requires a random access procedure, or if BFI_COUNTER >= beamFailureInstanceMaxCount of the target LTM candidate cell or the timeAlignmentTimer associated with the target LTM candidate cell (or the TAG to which the target LTM cell belongs) is not running, or if the first MAC CE does not include a TA value (i.e., a timed advance command), or if the first MAC CE indicates that a random access procedure is required via an indicator (e.g., a special TA value) (in another embodiment, a second RRCReconfigurationComplete message may be generated when the LTM cell handover (LTM execution) completes successfully): 2> Set the content of the RRCReconfigurationComplete message as follows: 3> Includes LTM candidate cell configuration / information (e.g., cell identifier or UE identifier or configuration index or configuration identifier) ​​of the target cell indicated from a lower layer (e.g., as indicated by the LTM trigger MAC CE).

[0228] Note: If this process is initiated to generate a complete LTM candidate cell configuration, even if the UE processes both the LTM reference configuration and the LTM candidate cell configuration, the UE should only generate one RRCReconfigurationComplete message. The RRCReconfigurationComplete message includes the contents of the target cell indicated by the LTM-triggered MAC CE.

[0229] 1> If the RRCReconfiguration message includes ltm-CandidateConfig (LTM candidate cell configuration): 2> Perform the LTM configuration process specified in 3.3.1.3; 4> Configure the content of the RRCReconfigurationComplete message as follows: Note: If this process is initiated to generate a complete LTM candidate cell configuration, even if the UE processes both the LTM reference configuration and the LTM candidate cell configuration, the UE should only generate one RRCReconfigurationComplete message. The RRCReconfigurationComplete message includes the contents of the target cell indicated by the LTM-triggered MAC CE.

[0230] 2> If RRCReconfiguration includes a masterCellGroup containing reportUplinkTxDirectCurrent: 3> Includes uplinkTxDirectCurrentList for each MCG serving cell with UL; 3> Include uplinkDirectCurrentBWP-SUL (if any) for each MCG serving cell configured with a SUL carrier in the uplinkTxDirectCurrentList; 2> If RRCReconfiguration includes a masterCellGroup containing reportUplinkTxDirectCurrentTwoCarrier: 3> Include a list of uplink Tx DC locations for in-band uplink carrier aggregation configured in the MCG in the uplinkTxDirectCurrentTwoCarrierList; 2> If RRCReconfiguration includes a masterCellGroup containing reportUplinkTxDirectCurrentMoreCarrier: 3> The uplinkTxDirectCurrentMoreCarrierList includes a list of uplink Tx DC locations configured in the MCG for in-band uplink carrier aggregation; 2> If RRCReconfiguration includes a secondaryCellGroup containing reportUplinkTxDirectCurrent: 3> Includes a list of uplinkTxDirectCurrentList for each SCG serving cell with UL; 3> Include uplinkDirectCurrentBWP-SUL (if any) for each SCG serving cell configured with a SUL carrier in the uplinkTxDirectCurrentList; 2> If RRCReconfiguration includes a secondaryCellGroup containing reportUplinkTxDirectCurrentTwoCarrier: 3> Include a list of uplink Tx DC locations for in-band uplink carrier aggregation configured in the SCG in the uplinkTxDirectCurrentTwoCarrierList; 2> If RRCReconfiguration includes a secondaryCellGroup containing reportUplinkTxDirectCurrentMoreCarrier: 3> Include a list of uplink Tx DC locations for in-band uplink carrier aggregation configured in SCG in uplinkTxDirectCurrentMoreCarrierList; Note 0b: The UE does not expect to receive either reportUplinkTxDirectCurrentTwoCarrier or reportUplinkTxDirectCurrentMoreCarrier in either the masterCellGroup or the secondaryCellGroup. The network configures at most one of reportUplinkTxDirectCurrent, reportUplinkTxDirectCurrentTwoCarrier, or reportUplinkTxDirectCurrentMoreCarrier in a single RRC message.

[0231] 2> If the RRCReconfiguration message includes a SecondaryCellGroupConfig with an mrdc-SecondaryCellGroup set to eutra-SCG: 3> According to Section 5.3.5.3 of TS 36.331

[10] , the E-UTRA RRCConnectionReconfigurationComplete message is included in the eutra-SCG-Response; 2> If the RRCReconfiguration message includes an mrdc-SecondaryCellGroupConfig with an mrdc-SecondaryCellGroup set to nr-SCG: 3> Include the SCG RRCReconfigurationComplete message in nr-SCG-Response; 3> If an RRCReconfiguration message was applied due to conditional reconfiguration execution, and the RRCReconfiguration message is not included in the masterCellGroup under the reconfigurationWithSync message: 4> Include the condReconfigId of the selected cell for conditional reconfiguration in selectedCondRRCReconfig; 2> If RRCReconfiguration includes reconfigurationWithSync in MCG's spCellConfig: 3> If the UE has a recorded measurement available for NR, and if the RPLMN is included in the plmn-IdentityLis stored in the VarLogMeasReport: 4> Include logMeasAvailable in the RRCReconfigurationComplete message; 4> If the Bluetooth measurement results are included in the measurements that the UE has recorded and that can be used for NR: 5> Include logMeasAvailableBT in the RRCReconfigurationComplete message; 4> If the WLAN measurement results are included in the measurements that the UE has recorded and that can be used for NR: 5> The RRCReconfigurationComplete message includes logMeasAvailableWLAN; 3> If sigLoggedMeasType from VarLogMeasReport is included: 4> If the T330 timer is running and the recorded measurement configuration is used for NR: 5> Set sigLogMeasConfigAvailable to true in the RRCReconfigurationComplete message; 4> Otherwise: 5> If the UE has measurements that can be used for NR recording: 6> Set sigLogMeasConfigAvailable to false in the RRCReconfigurationComplete message; 3> If the UE has available connection establishment failure or connection recovery failure information in VarConnEstFailReport or VarConnEstFailReportList, and if RPLMN equals the plmn-Identity in at least one of the entries stored in VarConnEstFailReport or VarConnEstFailReportList: 4> Include connEstFailInfoAvailable in the RRCReconfigurationComplete message; 3> If the UE has available radio link failure or handover failure information in the VarRLF-Report, and if the RPLMN is included in the plmn-IdentityList stored in the VarRLF-Report; or 3> If the UE has available radio link failure or handover failure information in the VarRLF-Report of TS 36.331

[10] , and if the UE is able to make cross-RAT RLF reports, and if the RPLMN is included in the plmn-IdentityList stored in the VarRLF-Report of TS 36.331

[10] : 4> Include rlf-InfoAvailable in the RRCReconfigurationComplete message; 3> If the UE configured successHO-Config when connecting to the source Pcell; and 3> If the applied RRCReconfiguration is not due to conditional reconfiguration performed during cell selection at the timer T311 runtime, as defined in 5.3.7.3: 4> Upon successful completion of the random access procedure triggered by reconfigurationWithSync in spCellConfig for MCG, perform the actions required for determining the successful handover report as specified in Section 5.7.10.6; 3> If the UE has available successful handover information in the VarSuccessHO-Report, and if the RPLMN is included in the plmn-IdentityList stored in the VarSuccessHO-Report: 4> Include successHO-InfoAvailable in the RRCReconfigurationComplete message; 2> If the RRCReconfiguration message is received via SRB1, but not in mrdc-SecondaryCellGroup, E-UTRA RRCConnectionReconfiguration, or E-UTRARRCConnectionResume: 3> If the UE is configured to provide measurement gap requirement information for the NR target frequency band: 4> If the RRCReconfiguration message includes needForGapsConfigNR; or 4> If the NeedForGapsInfoNR information has changed since the UE last reported this information: 5> Include NeedForGapsInfoNR and set its contents as follows: 6> Includes intraFreq-needForGap, and sets gap requirement information for co-frequency measurements for each NR serving cell; 6> If requestedTargetBandFilterNR is configured: 7> For each supported NR band that is also included in requestedTargetBandFilterNR, include an entry in interFreq-needForGap and set the gap requirement information for that band; 6> Otherwise: 7> Include entries in interFreq-needForGap and set the corresponding gap requirement information for each supported NR band; 3> If the UE is configured to provide NR target band measurement gap and NCSG requirement information: 4> If the RRCReconfiguration message includes needForGapNCSG-ConfigNR; or 4> If the needForGapNCSG-InfoNR information has changed since the UE last reported this information: 5> Include NeedForGapNCSG-InfoNR and set its contents as follows: 6> Includes intraFreq-needForNCSG, and sets the interval for co-frequency measurements and NCSG requirement information for each NR serving cell; 6> If requestedTargetBandFilterNCSG-NR is configured: 7> For each supported NR band included in requestedTargetBandFilterNCSG-NR, include an entry in interFreq-needForNCSG and set the NCSG requirement information for that band; 6> Otherwise: 7> Include entries for each supported NR band in interFreq-needForNCSG and set the corresponding NCSG requirement information; 3> If the UE is configured to provide EUTRA target band measurement gap and NCSG requirement information: 4> If the RRCReconfiguration message includes needForGapNCSG-ConfigEUTRA; or 4> If the needForGapNCSG-InfoEUTRA information has changed since the UE last reported this information: 5> Include NeedForGapNCSG-InfoEUTRA and set its contents as follows: 6> If requestedTargetBandFilterNCSG-EUTRA is configured, for each supported E-UTRA band included in requestedTargetBandFilterNCSG-EUTRA, an entry is included in needForNCSG-EUTRA and NCSG requirement information is set for that band; otherwise, an entry is included in needForNCSG-EUTRA for each supported E-UTRA band and the corresponding NCSG requirement information is set. 2> If the process is initiated to generate a complete LTM candidate cell configuration: 3> Process ends.

[0232] RRCReconfigurationComplete

[0233] As described above, during the LTM execution process, or when the target LTM cell configuration is applied (indicated by the configuration identifier in the first MAC CE), or when the first MAC CE is received in option 1, option 2, or option 3 (e.g., if a random access procedure (or no RACH solution) is triggered when an LTM trigger MAC CE is received), an RRCReconfigurationComplete message is generated and sent to the target LTM candidate cell.

[0234] For options 1, 2, or 3, this application also proposes how to submit the RRCReconfigurationComplete message via which SRB during the LTM execution process, which is also extended to dual-connectivity scenarios (e.g., for UEs configured with MCG and SCG). As proposed in this disclosure, the LTM candidate cell configuration can be configured via the RRCReconfiguration message via SRB1 or separate SRB1 or SRB3. The LTM candidate cell configuration for MCG or SCG can be configured via the RRCReconfiguration message via SRB1 or separate SRB1 or SRB3. The RRCReconfiguration message including the LTM candidate cell configuration does not include reconfigurationWithSync to avoid handover triggered by the RRC message.

[0235] A UE configured with single connectivity (i.e., MCG only) or without dual connectivity (i.e., MCG and SCG or MCG) can be configured with an LTM candidate cell configuration (e.g., for MCG) by receiving a first RRCReconfiguration message via SRB1. A first RRCReconfigurationComplete message corresponding to the first RRCReconfiguration can then be generated and sent to the source serving cell (primary gNB, i.e., MCG) via SRB1, which sent the first RRCReconfiguration message to the UE. When the UE receives a first MAC CE including a target LTM configuration ID (identifier) ​​from the source serving cell, the UE can apply the corresponding target LTM configuration (e.g., for MCG) indicated by the configuration ID in the first MAC CE (or the RRCReconfiguration of the target LTM cell for MCG). Upon receiving the first MAC CE or applying the target LTM configuration, the UE generates a second RRCReconfigurationComplete corresponding to the target LTM configuration, which has content (e.g., configuration ID or information for the target LTM configuration, or a reply or confirmation), and sends the second RRCReconfigurationComplete to the target cell (or gNB or MCG) via SRB1. In another embodiment, the second RRCReconfigurationComplete message can be generated when the LTM cell handover (LTM execution) is successfully completed.

[0236] Furthermore, this application proposes how to submit the first RRCReconfigurationComplete, as shown below (which can also be applied to UEs configured with dual connectivity): 1> If the UE is configured with E-UTRA nr-SecondaryCellGroupConfig (UE is in (NG)EN-DC): 2> Submit the first RRCReconfigurationComplete via E-UTRA; 1> Otherwise, if the first RRCReconfiguration message is received via SRB3 (UE is in NR-DC): 2> If the first RRCReconfiguration message is received in DLInformationTransferMRDC: 3> If the first RRCReconfiguration message is received in the nr-SCG within the mrdc-SecondaryCellGroup (NR SCG RRC Reconfiguration): 4> Perform SCG reconfiguration accordingly: 3> Otherwise (e.g., the first RRCReconfiguration message is received within the primary cell group configuration (NR MCG RRCReconfiguration): 4> Submit the first RRCReconfigurationComplete message to the lower layer via SRB1 to transmit with the new configuration; 2> Otherwise: 3> Submit the first RRCReconfigurationComplete message to the lower layer via SRB3 to transmit with the new configuration; 1> Otherwise (the first RRCReconfiguration is received via SRB1): 2> The first RRCReconfigurationComplete message is submitted to the lower layer via SRB1 to transmit with the new configuration; A UE configured with dual connectivity (i.e., MCG and SCG) can be configured with LTM candidate cell configuration (e.g., for MCG or SCG) by receiving a first RRCReconfiguration message via SRB1 (or separate SRB1) or SRB3. A first RRCReconfigurationComplete message corresponding to the first RRCReconfiguration can be generated and sent to the source serving cell.

[0237] For each case of dual connectivity, this application proposes how to submit a second RRCReconfigurationComplete, as follows: When the UE is configured with an LTM candidate cell configuration for the SCG, or when cell handover is triggered from a lower layer (e.g., by receiving an LTM-triggered MAC CE from the SCG's MAC entity, or by receiving an LTM cell handover execution in the SCG), or if a target LTM candidate cell configuration for the SCG is applied due to LTM candidate cell execution, the UE generates a second RRCReconfigurationComplete message. Then, if the UE is configured with E-UTRAnr-SecondaryCellGroupConfig (the UE is in (NG)EN-DC), the UE submits a second RRCReconfigurationComplete via E-UTRA. In another embodiment, a second RRCReconfigurationComplete message may be generated when the LTM cell handover (LTM execution) completes successfully.

[0238] If the UE is configured with an LTM candidate cell configuration for the SCG, or if the LTM cell handover is triggered from a lower layer (e.g., by receiving an LTM-triggered MAC CE from the SCG in the SCG's MAC entity, or by receiving an LTM cell handover in the SCG), or if a target LTM candidate cell configuration for the SCG is applied due to LTM candidate cell execution, the UE generates a second RRCReconfigurationComplete message. Then, if an RRCReconfiguration message (or an LTM candidate configuration for the SCG) is received in the nr-SCG within the mrdc-SecondaryCellGroup via SRB1 (the UE is in the NR-DC and receives the mrdc-SecondaryCellGroup via SRB1 in RRCReconfiguration or RRCResume), the UE submits a second RRCReconfigurationComplete message embedded in the NR RRC message ULInformationTransferMRDC via the NR MCG (e.g., submitted to the SCG or MCG via SRB1 (or via a separate SRB1)). In another embodiment, a second RRCReconfigurationComplete message may be generated when the LTM cell handover (LTM execution) is successfully completed.

[0239] If the UE is configured to receive via SRB3 (UE is in NR-DC), and if an RRCReconfiguration message (or LTM candidate configuration for SCG) is received within DLInformationTransferMRDC, and no RRCReconfiguration message is received within nr-SCG in mrdc-SecondaryCellGroup (i.e., it is not NR SCG RRC reconfiguration, or if the target LTM candidate cell configuration for SCG is applied, or if LTM cell handover is triggered from a lower layer (e.g., by receiving LTM from SCG in the MAC entity of SCG to trigger MAC CE, or by receiving LTM cell handover in SCG), or if the target LTM candidate cell configuration for SCG is applied due to LTM candidate cell execution, then the UE generates a second RRCReconfigurationComplete message. Then, if the primary cell group configuration (i.e., it is NR MCG) is applied... If the UE receives an RRCReconfiguration message (or an LTM candidate configuration for the SCG) as an LTM candidate configuration in the RRCReconfiguration process, it submits a second RRCReconfigurationComplete message to the lower layer via SRB1 to transmit with the new configuration. This is because DLInformationTransferMRDC includes the configuration from the MCG, which needs to be sent to the MCG via SRB1. In another embodiment, the second RRCReconfigurationComplete message can be generated when the LTM cell handover (LTM execution) is successfully completed.

[0240] If the UE is configured with an LTM candidate cell configuration for the SCG, or if the LTM cell handover is triggered from a lower layer (e.g., by receiving an LTM-triggered MAC CE from the SCG in the SCG's MAC entity, or by receiving an LTM cell handover execution in the SCG), or if a target LTM candidate cell configuration for the SCG is applied due to LTM candidate cell execution, the UE generates a second RRCReconfigurationComplete message. Then, if an RRCReconfiguration message (or an LTM candidate configuration for the SCG) is received via SRB3 (the UE is in the NR-DC), and if no RRCReconfiguration message (or an LTM candidate configuration for the SCG) is received within DLInformationTransferMRDC, the UE submits the second RRCReconfigurationComplete message to the lower layer via SRB3 for transmission with the new configuration, because this configuration corresponds to the SCG and needs to be sent to the MCG via SRB3. In another embodiment, the second RRCReconfigurationComplete message can be generated when the LTM cell handover (LTM execution) is successfully completed.

[0241] If the UE is configured with an LTM candidate cell configuration for the SCG, or if the LTM cell handover is triggered from a lower layer (e.g., by receiving an LTM-triggered MAC CE from the SCG's MAC entity, or by receiving an LTM cell handover execution in the SCG), or if a target LTM candidate cell configuration for the SCG is applied due to LTM candidate cell execution, the UE generates a second RRCReconfigurationComplete message. Then, if RRCReconfiguration (or an LTM candidate configuration for the SCG) is received via SRB1, the UE submits the second RRCReconfigurationComplete message to the lower layer via SRB1 for transmission with the new configuration. In another embodiment, the second RRCReconfigurationComplete message may be generated when the LTM cell handover (LTM execution) completes successfully.

[0242] To implement the above proposal, specifically, the UE should perform the following actions upon receiving an RRCReconfiguration, or when performing a conditional reconfiguration (CHO, CPA, or CPC), or when performing an LTM procedure (or LTM cell handover): 1> If the LTM cell handover is triggered from a lower layer (e.g., by receiving an LTM-triggered MACCE or LTM cell handover execution in the MAC entity), or if the target LTM candidate cell configuration is applied due to LTM candidate cell execution: 2> Configure the content of the second RRCReconfigurationComplete message as follows: 3> Includes LTM candidate cell configuration / information (e.g., cell identifier or UE identifier or configuration index or configuration identifier) ​​of the target cell indicated from a lower layer (e.g., as indicated by the LTM-triggered MAC CE). 3> If the RRCReconfiguration message includes an mrdc-SecondaryCellGroupConfig with an mrdc-SecondaryCellGroup set to nr-SCG: 4> Include the SCG RRCReconfigurationComplete message in nr-SCG-Response; 4> If an RRCReconfiguration message is applied due to conditional reconfiguration execution, and the RRCReconfiguration message does not include reconfigurationWithSync in the masterCellGroup: 5> Include the condReconfigId of the selected cell for conditional reconfiguration in selectedCondRRCReconfig; 4> If RRCReconfiguration (or target LTM candidate configuration) is applied due to the execution of an LTM candidate cell for LTM cell handover via an LTM candidate cell configuration included in the mrdc-SecondaryCellGroup (e.g., triggered by the reception of the first MAC CE): 5> The selected LTM candidate configuration includes the configuration ID (identifier) ​​of the selected LTM candidate cell for LTM execution. The configuration ID may be indicated by the first MAC CE; To simplify the network implementation for processing the second RRCReconfigurationComplete message, this application also proposes to submit the second RRCReconfigurationComplete message in the following manner: 1> If the UE is configured with E-UTRA nr-SecondaryCellGroupConfig (UE is in (NG)EN-DC): 2> Submit the second RRCReconfigurationComplete via E-UTRA; 1> Otherwise, if an RRCReconfiguration message (or target LTM candidate configuration) is received via SRB1 in an nr-SCG within the mrdc-SecondaryCellGroup (the UE is in NR-DC and receives the mrdc-SecondaryCellGroup via SRB1 in RRCReconfiguration or RRCResume): 2> If RRCReconfiguration is applied due to conditional reconfiguration for CPC configured via conditionalReconfiguration contained in nr-SCG within mrdc-SecondaryCellGroup; or 2> If RRCReconfiguration (or target LTM candidate configuration) is applied due to the execution of an LTM candidate cell for LTM cell handover via an LTM candidate cell configuration included in the mrdc-SecondaryCellGroup (e.g., triggered by the reception of the first MAC CE): 3> Submit the second RRCReconfigurationComplete message embedded in the NR RRC message ULInformationTransferMRDC via the NR MCG (e.g., via SRB1 (or via separate SRB1) to the SCG or MCG). For example, the UE should set the content of the ULInformationTransferMRDC message as follows: If NR-related MR-DC specific information needs to be transmitted, the UE sets ul-DCCH-MessageNR to include the NR MR-DC specific information to be transmitted (e.g., NR RRC MeasurementReport, UEAssistanceInformation, FailureInformation, RRCReconfigurationComplete, MCGFailureInformation, or IABOtherInformationmessage).

[0243] 1> Otherwise, if an RRCReconfiguration message (or target LTM candidate configuration) is received via SRB3 (UE is in NR-DC): 2> If an RRCReconfiguration message (or target LTM candidate configuration) is received in DLInformationTransferMRDC: 3> If an RRCReconfiguration message is received within nr-SCG of mrdc-SecondaryCellGroup (NR SCG RRC Reconfiguration): 4> Perform SCG reconfiguration accordingly: 3> Otherwise (e.g., if the target LTM candidate configuration is received within the primary cell group configuration (NR MCG RRCReconfiguration): 4> Submit the second RRCReconfigurationComplete message to the lower layer via SRB1 to transmit with the new configuration; 2> Otherwise: 3> Submit the second RRCReconfigurationComplete message to the lower layer via SRB3 to transmit with the new configuration; 1> Otherwise (receiving RRCReconfiguration (or target LTM candidate configuration) via SRB1): 2> Submit the second RRCReconfigurationComplete message to the lower layer via SRB1 to transmit with the new configuration; The DLInformationTransferMRDC message is used for downlink transmission of RRC messages via SRB3 during fast MCG link recovery, while the ULInformationTransferMRDC message is used for uplink transmission of MR-DC dedicated information via SRB1 or SRB3 (e.g., for transmitting NR or E-UTRA RRC MeasurementReport messages, FailureInformation messages, UEAssistanceInformation messages, RRCReconfigurationComplete messages, IABOtherInformation messages, or NR or E-UTRA RRC MCGFailureInformation messages).

[0244] In another embodiment, a UE configured with dual connectivity (i.e., MCG and SCG) can be configured with an LTM candidate cell configuration (e.g., for MCG or SCG) by receiving a first RRCReconfiguration message via SRB1 (or separate SRB1) or SRB3. A first RRCReconfigurationComplete message corresponding to the first RRCReconfiguration can be generated and sent to the source serving cell.

[0245] For each case of dual connectivity, this application proposes how to submit a second RRCReconfigurationComplete, as follows: If the UE is configured with an LTM candidate cell configuration for the MCG, or if the LTM cell handover is triggered from a lower layer (e.g., by receiving an LTM-triggered MAC CE from the MCG in the MCG's MAC entity, or by receiving an LTM cell handover execution in the MCG), or if a target LTM candidate cell configuration for the MCG is applied due to an LTM candidate cell execution, the UE generates a second RRCReconfigurationComplete message. Then, if an RRCReconfiguration message (or an LTM candidate configuration for the MCG) is received via SRB1, the UE submits the second RRCReconfigurationComplete message to the lower layer via SRB1 for transmission with the new configuration. In another embodiment, the second RRCReconfigurationComplete message may be generated when the LTM cell handover (LTM execution) completes successfully.

[0246] If the UE is configured with an LTM candidate cell configuration for the SCG, or if the LTM cell handover is triggered from a lower layer (e.g., by receiving an LTM-triggered MAC CE from the SCG in the SCG's MAC entity, or by receiving an LTM cell handover in the SCG), or if a target LTM candidate cell configuration for the SCG is applied due to LTM candidate cell execution, the UE generates a second RRCReconfigurationComplete message. Then, if an RRCReconfiguration message (or an LTM candidate configuration for the SCG) is received in the nr-SCG within the mrdc-SecondaryCellGroup via SRB1 (the UE is in the NR-DC and receives the mrdc-SecondaryCellGroup via SRB1 in RRCReconfiguration or RRCResume), the UE submits a second RRCReconfigurationComplete message embedded in the NR RRC message ULInformationTransferMRDC via the NR MCG (e.g., submitted to the SCG or MCG via SRB1 (or via a separate SRB1)). In another embodiment, a second RRCReconfigurationComplete message may be generated when the LTM cell handover (LTM execution) is successfully completed.

[0247] When the UE is configured with an LTM candidate cell configuration for the SCG, or when cell handover is triggered from a lower layer (e.g., by receiving an LTM-triggered MAC CE from the SCG in the SCG's MAC entity, or by receiving an LTM cell handover execution in the SCG), or if a target LTM candidate cell configuration for the SCG is applied due to LTM candidate cell execution, the UE generates a second RRCReconfigurationComplete message. Then, if an RRCReconfiguration message (or an LTM candidate configuration for the SCG) is received via SRB3 (the UE is in the NR-DC), and if no RRCReconfiguration message (or an LTM candidate configuration for the SCG) is received within DLInformationTransferMRDC, the UE submits the second RRCReconfigurationComplete message to the lower layer via SRB3 for transmission with the new configuration, because this configuration corresponds to the SCG, needs to be sent to the SCG via SRB3, and the DLInformationTransferMRDC message is used for downlink transmission of RRC messages during fast MCG link recovery. In another embodiment, a second RRCReconfigurationComplete message may be generated when the LTM cell handover (LTM execution) is successfully completed.

[0248] If the UE is configured with an LTM candidate cell configuration for the SCG, or if the LTM cell handover is triggered from a lower layer (e.g., by receiving an LTM-triggered MAC CE from the SCG in the SCG's MAC entity, or by receiving an LTM cell handover execution in the SCG), or if a target LTM candidate cell configuration for the SCG is applied due to LTM candidate cell execution, the UE generates a second RRCReconfigurationComplete message. Then, if RRCReconfiguration (or an LTM candidate configuration for the SCG) is received via SRB1, the UE submits the RRCReconfigurationComplete message to the lower layer via SRB1 for transmission with the new configuration. In another embodiment, the second RRCReconfigurationComplete message may be generated when the LTM cell handover (LTM execution) completes successfully.

[0249] In another embodiment, a UE configured with dual connectivity (i.e., MCG and SCG) can be configured with an LTM candidate cell configuration (e.g., for MCG or SCG) by receiving a first RRCReconfiguration message via SRB1 (or separate SRB1) or SRB3. A first RRCReconfigurationComplete message corresponding to the first RRCReconfiguration can be generated and sent to the source serving cell.

[0250] For each case of dual connectivity, this application proposes how to submit a second RRCReconfigurationComplete, as follows: If the UE is configured with an LTM candidate cell configuration for the MCG (or SCG), or if the LTM cell handover is triggered from a lower layer (e.g., by receiving an LTM-triggered MAC CE from the MCG (or SCG) in the MAC entity of the MCG (or SCG), or by receiving an LTM cell handover in the MCG (or SCG), or if a target LTM candidate cell configuration for the MCG (or SCG) is applied due to the LTM candidate cell execution, the UE generates a second RRCReconfigurationComplete message.

[0251] Then, the UE submits the second RRCReconfigurationComplete as follows: (In another embodiment, the second RRCReconfigurationComplete message can be generated when the LTM cell handover (LTM execution) is successfully completed).

[0252] 1> If the UE is in (NG) EN-DC: 2> If SRB3 is configured, or SCG is not deactivated: 3> The second RRCReconfigurationComplete is submitted to the lower layer via SRB3 for transmission, thus ending the process; 2> Otherwise: 3> Submit RRCReconfigurationComplete, which is embedded in the E-UTRA RRC message ULInformationTransferMRDC, via E-UTRA.

[0253] 1> Otherwise, if the UE is in NR-DC: 2> If the LTM candidate cell configuration is associated with SCG: 3> If SRB3 is configured, or SCG is not deactivated: 4> The second RRCReconfigurationComplete is submitted to the lower layer via SRB3 for transmission, thus ending the process; 3> Otherwise: 4> Submit RRCReconfigurationComplete embedded in the NR RRC message ULInformationTransferMRDC via SRB1; 2> Otherwise: 3> The second RRCReconfigurationComplete is submitted to the lower layer via SRB1 for transmission, thus ending the process; 1> Otherwise (i.e., the UE is configured with a single connection): 2> Submit the second RRCReconfigurationComplete to the lower layer for transmission. This completes the process.

[0254] In this disclosure, an LTM execution procedure for the SCG can be performed if the SCG is not deactivated (or when the SCG is not deactivated), or if the SCG is activated (or when the SCG is activated).

[0255] LTM Configuration and Execution

[0256] In this embodiment, the LTM configuration for a candidate cell can indicate either a reference configuration or a complete configuration for the LTM candidate cell. The reference configuration can be either a complete configuration or a reference configuration, and the LTM candidate cell-specific configuration can be the complete configuration for the LTM candidate cell.

[0257] During LTM execution, the UE can suspend all radio bearers except SRBs (e.g., SRB0, SRB1, SRB2, SRB3, SRB4, or SRB5) to avoid data processing or transmission (or reception) to the source cell, or to avoid data transmission during the random access procedure to the target cell. After successfully completing LTM execution (or LTM cell handover to the target cell), the UE can resume all suspended radio bearers except SRBs to begin data transmission or reception.

[0258] The UE should perform the following actions based on the received LTM-CandidateConfig IE: 1> If it exists, the received ltm-ReferenceConfiguration will be stored in VarLTM-Config; 1> If LTM-CandidateConfig includes ltm-CandidateToReleaseList: 2> Execute LTM candidate cell release; 1> If LTM-CandidateConfig includes ltm-CandidateToAddModList: 2> Perform LTM candidate cell addition or reconfiguration; 1> Perform the operation to generate a complete LTM configuration; Note: Whether to postpone generating the complete LTM configuration until LTM cell handover is performed depends on the UE implementation.

[0259] LTM candidate cell release

[0260] UE should: 1> For each ltm-CandidateId in ltm-CandidateToReleaseList: 2> If the current VarLTM-Config includes an ltm-Candidate with a given ltm-CandidateId: 3> Release ltm-Candidate from VarLTM-Config; The UE may automatically release the LTM candidate cell configuration (or it may release it via an explicit indicator in a received RRC message) under the following conditions: - When LTM execution (or LTM cell handover) is successfully completed - Upon receiving the RRC Release message (because LTM execution is only available in RRC connection state). - If RRCSetup is received in response to RRCReestablishmentRequest (because this means that the UE failed to successfully complete the RRC rebuild process when it sent RRCReestablishmentRequest to restore the RRC connection with the network), the RRCSetup message is used to establish SRB1 and is sent (or received) via SRB0.

[0261] In another embodiment, the UE can release the LTM candidate cell configuration upon receiving an RCRelease message indicating a transition to RRC idle mode, and can store or retain the configuration upon receiving an RCRelease message indicating a transition to RRC inactive mode. This configuration can be reconfigured or used to restore RRC connectivity using an RCRResume message. For example, the RCRelease message indicating a state transition to RRC inactive can also indicate whether the UE retains or releases the LTM candidate cell configuration. When the UE performs the RRC recovery procedure, the network can send an RCResume message including an indicator of whether to restore or release the LTM candidate cell configuration.

[0262] LTM candidate cells added / modified

[0263] UE should: 1> For each ltm-CandidateId in ltm-CandidateToAddModList: 2> If the current VarLTM-Config includes an ltm-Candidate with a given ltm-CandidateId: 3> Modify the ltm-Candidate in VarLTM-Config according to the received ltm-Candidate; 2> Otherwise: 3> Add the received ltm-Candidate to VarLTM-Config.

[0264] Generate UE LTM configuration

[0265] The purpose of this process is for the UE to generate a complete LTM candidate cell configuration (or LTM candidate cell configuration) for each LTM candidate cell to be stored, and to apply the LTM candidate cell configuration of the target cell indicated by the lower layer (i.e., as indicated by the LTM trigger MAC CE) only when the lower layer receives an indication of LTM cell handover. The current UE configuration should not be modified during the generation of the complete LTM candidate cell configuration.

[0266] UE should: 1> For each ltm-Candidate in ltm-CandidateConfigList within VarLTM-Config; 2> Store the ltm-CandidateId included in ltm-Candidate in VarLTM-UE-Config; 2> If ltm-Candidate includes ltm-ConfigComplete; 3> Generate a complete LTM candidate cell configuration based on the received ltm-Candidate based on the action, and store it in ue-LTM-Config in VarLTM-UE-Config.

[0267] 2> Otherwise: 3> Based on the action, apply ltm-Candidate on the basis of referenceConfiguration to generate a complete LTM candidate cell configuration and store it in ue-LTM-Config in VarLTM-UE-Config.

[0268] LTM cell handover execution

[0269] When an LTM cell handover procedure is triggered by a lower-layer indication, the UE should: 1>Release / clear all current private wireless configurations except for the following: - SRB1 / SRB2 configuration and DRB configuration configured by radioBearerConfig or radioBearerConfig2; -UE variables VarLTM-Config and VarLTM-UE-Config.

[0270] 1> Release / clear all current public radio configurations associated with the cell group targeted by the LTM cell handover procedure; 1> Use the default values ​​specified for timers T310, T311 and constants N310, N311 associated with the cell group that triggers the LTM cell handover process; 1> Except for the following parameters, apply the default L1 parameter values ​​as specified in the corresponding physical layer specification: - The parameters with values ​​provided in SIB1 (i.e., system information); 1> Based on the LTM candidate cell configuration related to the LTM candidate cell configuration identifier received by the lower layer, apply the value of newUE-Identity as the C-RNTI of the cell group; 1> Configure the lower layer according to the LTM candidate cell configuration indicated by the lower layer, based on the received spCellConfigCommon; 1> Configure the lower layer according to the LTM candidate cell configuration indicated by the lower layer, based on the received rach-ConfigDedicated.

[0271] 1> Continue using the state variables for SRB, and configure the PDCP entity for LTM candidate cell configuration indicated by the lower layer using the same security configuration as for the PDCP entity for the source cell group; 1> If timer T310 for the corresponding SpCell is running, stop the timer; 1> If this procedure is performed against MCG: 2> If timer T316 is running; 3> Stop timer T316; 1> If timer T312 for the corresponding SpCell is running, stop the timer; 1> Start a monitoring timer (i.e., T3xx) for this cell group, and set its timer value to the configuration value in RRCReconfiguration, such as the value included in the ltm-Timers field; 1> Reset the MAC entity of this cell group; 1> Configure the BCCH configuration specified by the application for the target LTM candidate cell; 1> Obtain the MIB of the target SpCell indicated in the LTM candidate cell configuration of the lower layer indication (if applicable); 1> The LTM configuration in UE-LTM-Config within VarLTM-UE-Config is related to the LTM candidate cell configuration identifier received at lower layers.

[0272] 1> Submit the RRCReconfigurationComplete message to the lower layer to transmit with the new configuration.

[0273] The LTM cell handover execution procedure described above can be extended to cover dual connectivity scenarios. When a UE is configured with dual connectivity (i.e., MCG and SCG), the LTM execution procedure can be initiated in either the MCG or SCG. However, it should be noted that this procedure will have some impact on the MCG failure recovery procedure. MCG failure recovery is primarily managed by a timer (i.e., T316). The purpose of MCG failure recovery is to notify the network that the UE has experienced an MCG failure, i.e., an MCG radio link failure, by sending an RRC message (i.e., an MCG failure information message) via the SCG (i.e., via a separate SRB1 or SRB3). A UE in an RRC connection can initiate a fast MCG link recovery procedure to continue the RRC connection without re-establishment, where AS security is activated for the UE and SRB2 and at least one DRB or multicast MRB or SRB2 (for IAB) are established. A UE configured with a separate SRB1 or SRB3 can initiate this procedure to report an MCG failure when neither MCG nor SCG transmissions are suspended, the SCG is not deactivated, T316 is configured, and an MCG radio link failure is detected while the T316 is not running. When the MCG failure is notified to the MCG, the MCG can send an RRC release message via the SCG (i.e., via a separate SRB1 or SRB3), an RRC reconfiguration message for the PCell with reconfigurationwithSync (i.e., a handover indication), or a MobilityFromNRCommand message to release or restore the RRC connection.

[0274] Timer T316 can only be configured when the UE is configured with either a separate SRB1 or SRB3. When the UE sends an RRC message (i.e., an MCG failure information message), the UE starts timer T316. If SRB1 is configured as a separate SRB, the UE submits the MCG failure information message to the lower layer via SRB1 for transmission. Otherwise (i.e., if SRB3 is configured), the UE submits the MCG failure information message embedded in the NR RRC message ULInformationTransferMRDC to the lower layer via SRB3 for transmission. Timer T316 is stopped when the UE receives an RRC release message, an RRC reconfiguration message with reconfigurationwithSync (i.e., a handover indication) for the PCell, or a MobilityFromNRCommand message, or when initiating an RRC reconstruction procedure. When timer T316 expires, the UE initiates the RRC reconstruction procedure.

[0275] Considering the MCG failure recovery process described above, if T316 is running, it means that an MCG failure has already occurred. Therefore, the scenario of initiating LTM cell handover execution while T316 is running needs careful consideration. To efficiently handle this situation, this application proposes the following option: An option can be implemented to perform LTM execution.

[0276] Option 1: In this option, if the UE receives the first MAC CE while T316 is running and is about to initiate an LTM cell handover procedure, the UE can stop T316 and execute the LTM cell handover procedure. This is because the LTM cell handover procedure can restore the MCG radio link through cell handover, which can speed up MCG failure recovery. The corresponding procedure is as follows: When an LTM cell handover procedure is triggered by a lower-layer indication, the UE should: 1>Release / clear all current private wireless configurations except for the following: - SRB1 / SRB2 configuration and DRB configuration configured by radioBearerConfig or radioBearerConfig2; -UE variables VarLTM-Config and VarLTM-UE-Config.

[0277] 1> Release / clear all current public wireless configurations; 1> Use the default values ​​specified for timers T310 and T311 and constants N310 and N311; 1> Except for the following parameters, apply the default L1 parameter values ​​as specified in the corresponding physical layer specification: - The parameter provides the value in SIB1; 1> Based on the LTM candidate cell configuration related to the LTM candidate cell configuration identifier received by the lower layer, apply the value of newUE-Identity as the C-RNTI of the cell group; 1> Configure the lower layer according to the LTM candidate cell configuration indicated by the lower layer, based on the received spCellConfigCommon; 1> Configure the lower layer according to the LTM candidate cell configuration indicated by the lower layer, based on the received rach-ConfigDedicated.

[0278] 1> Utilize continuous state variables for SRB and configure the PDCP entity for LTM candidate cell configuration indicated by the lower layer using the same security configuration as for the PDCP entity used for the source cell group; 1> If timer T310 for the corresponding SpCell is running, stop the timer; 1> If the LTM message switching procedure (i.e., LTM execution) is performed against the MCG: 2> If timer T316 is running; 3> Stop timer T316; 1> If timer T312 for the corresponding SpCell is running, stop the timer; 1> The application is configured with the specified BCCH configuration defined for the target LTE candidate cell; 1> Obtain the MIB of the target SpCell indicated in the LTM candidate cell configuration of the lower layer indication (if applicable); 1> The LTM configuration in UE-LTM-Config within VarLTM-UE-Config is related to the LTM candidate cell configuration identifier received by the lower layer.

[0279] 2> Submit the RRCReconfigurationComplete message to the lower layer to transmit with the new configuration.

[0280] Option 2: In this option, if the UE receives the first MAC CE while T316 is running and is about to initiate an LTM cell handover procedure, the UE will not perform the LTM cell handover procedure because it may be difficult for the MCG's CU to control. LTM cell handover can be triggered by the MCG's DU, which may lead to misalignment between the CU and DU. It should be noted that LTM cell handover can be performed within a cell group. When the T316 operation indicates that the MCG (Main Cell Group) radio link has failed, the UE can wait for a response from the MCG during the MCG failure recovery process instead of performing the LTM cell candidate procedure. The corresponding procedure is as follows.

[0281] When the LTM cell handover procedure is triggered by a lower layer indication, if T316 is not running (when T316 is not running), the UE should: 1>Release / clear all current private wireless configurations except for the following: - SRB1 / SRB2 configuration and DRB configuration configured by radioBearerConfig or radioBearerConfig2; -UE variables VarLTM-Config and VarLTM-UE-Config.

[0282] 1> Release / clear all current public wireless configurations; 1> Use the default values ​​specified for timers T310 and T311 and constants N310 and N311; 1> Except for the following parameters, apply the default L1 parameter values ​​as specified in the corresponding physical layer specification: - The parameter provides the value in SIB1; 1> Based on the LTM candidate cell configuration related to the LTM candidate cell configuration identifier received by the lower layer, apply the value of newUE-Identity as the C-RNTI of the cell group; 1> Configure the lower layer according to the LTM candidate cell configuration indicated by the lower layer, based on the received spCellConfigCommon; 1> Configure the lower layer according to the LTM candidate cell configuration indicated by the lower layer, based on the received rach-ConfigDedicated.

[0283] 1> Utilize continuous state variables for SRB and configure the PDCP entity for LTM candidate cell configuration indicated by the lower layer using the same security configuration as for the PDCP entity used for the source cell group; 1> If timer T310 for the corresponding SpCell is running, stop the timer; 1> If timer T312 for the corresponding SpCell is running, stop the timer; 1> The application is configured with the specified BCCH configuration defined for the target LTE candidate cell; 1> Obtain the MIB of the target SpCell indicated in the LTM candidate cell configuration of the lower layer indication (if applicable); 1> The LTM configuration in UE-LTM-Config within VarLTM-UE-Config is related to the LTM candidate cell configuration identifier received by the lower layer.

[0284] 3> Submit the RRCReconfigurationComplete message to the lower layer to transmit with the new configuration.

[0285] For the above options, the UE can stop T310 and T312 when initiating LTM execution, as these timers are used to monitor the radio link. For example, the UE starts T310 when it detects a physical layer problem with the SpCell (i.e., when it receives a pre-configured number of consecutive asynchronous indications from the lower layer); and stops T310 when it receives several consecutive synchronization indications for the SpCell from the lower layer, when it receives an RRCReconfiguration with reconfigurationWithSync for the cell group, when it receives a MobilityFromNRCommand, when it reconfigures rlf-TimersAndConstant, when it initiates a connection reconstruction procedure, when it performs a conditional reconfiguration (i.e., when it applies a stored RRCReconfiguration message with reconfigurationWithSync for the cell group), when it initiates an MCG failure information procedure, and when it performs an LTM cell handover. For example, if T312 is configured in the MCG, when a measurement report is triggered for a measurement flag that has T312 configured and whose useT312 value is set to true, and T310 in the PCell is running, the UE initiates T312; and the UE initiates T312 when it receives a pre-configured number of continuous synchronization indications from the lower layer SpCell, when it receives an RRCReconfiguration with reconfigurationWithSync for the cell group, when it receives a MobilityFromNRCommand, or when it reconfigures rlf-TimersAndConstant. T312 is stopped when: during the MCG failure information process; during conditional reconfiguration execution (i.e., when the stored RRCReconfiguration message including reconfigurationWithSync is applied for the cell group); when T310 in the corresponding SpCell expires; when SCG is released (if T312 is retained in SCG); if T312 is configured in SCG and useT312 is set to true; when a measurement report is triggered for a measurement identifier that has T312 configured; when LTM cell handover is performed; or when T310 in PSCell is running.

[0286] The following pertains to RRC messages. In the RRCReconfiguration message, each LTM candidate cell configuration (e.g., in the CellGroupConfig IE) may include one of the following information: - An indicator used to indicate whether DL synchronization to the candidate / target cell is performed before receiving a cell handover command (MAC CE).

[0287] - An LTM cell handover indicator (or cell identifier) ​​that instructs the UE to perform an LTM cell handover to the target cell (the candidate cell indicated by the indicator) upon receiving an RRCReconfiguration message. This can trigger an LTM cell handover earlier than a MACCE-based LTM cell handover, i.e., it does not require the network to send a MAC CE to the UE to trigger an LTM cell handover.

[0288] -LTM candidate cell configuration index (or identifier) ​​or cell identifier

[0289] -TCI status or beam information (e.g., beam index, SSB index, etc.)

[0290] After an LTM cell handover, the UE can retain the LTM candidate cell configuration, which allows for subsequent LTM cell handovers via MAC CE.

[0291] When the network triggers an L3-triggered handover to the UE (i.e., a handover via RRCReconfiguration including reconfigurationWithSync), if the handover or random access procedure to the target cell is successfully completed, the UE can automatically (or via RRCReconfiguration) release the LTM candidate cell configuration. Since PCells are changed after the handover and the LTM candidate cell configurations become invalid, they should be released and can be updated.

[0292] LTM candidate cell configuration: The configuration associated with LTM candidate cells. The LTM candidate cell configuration can be a complete LTM candidate cell configuration or an incremental (difference) configuration relative to the LTM reference configuration.

[0293] LTM Reference Configuration: A configuration provided to the UE by the network that is common to all LTM candidate cell configurations. The UE uses this configuration to generate a complete LTM candidate cell configuration (i.e., by applying the LTM candidate cell configuration based on the LTM Reference Configuration).

[0294] -LTM-CandidateConfig

[0295] IE LTM-CandidateConfig is used to provide LTM candidate cell configuration.

[0296] The following shows the details of the LTM-CandidateConfig information element:

[0297] The following pertains to timer handling (i.e., Txxx or custodian timers). The custodian timer can be used to detect failures in the LTM cell handover process, where the LTM process fails if the LTM custodian timer expires. When an LTM execution attempt fails or an RLF occurs, if the network is configured for the UE to attempt LTM after an LTM failure, the UE performs cell selection, and if the selected cell is an LTM candidate cell, the UE attempts a RACH-based LTM execution on that cell; otherwise, an RRC reconstruction is performed.

[0298] The behavior of the monitoring timer is as follows: - LTM oversight timers (e.g., Txx timers or T304 timers) can be managed for each cell group (e.g., MCG or SCG) in the RRC layer. The T304 timer can be reused for LTM oversight timers.

[0299] - The UE starts an LTM surveillance timer when it receives an LTM cell handover MAC CE. The UE can restart the LTM surveillance timer when it receives an LTM cell handover MAC CE indicating subsequent LTM. For example, the UE can start or restart the LTM surveillance timer when it receives an LTM cell handover MAC CE.

[0300] - The UE stops the LTM supervisory timer when it successfully completes an LTM cell handover (or when the MAC of the NR cell group successfully completes a random access procedure triggered for the LTM cell handover), or when a beam failure is detected (i.e., if BFI_COUNTER >= beamFailureInstanceMaxCount of the target / indicated LTM candidate cell (or PTAG or serving cell or target cell), or when it receives an RRCReconfiguration including reconfigurationWithSync.

[0301] - For MCG, a supervisory timer can be used to detect the failure of the LTM cell handover process. If the LTM supervisory timer expires, the LTM process fails. At this time, the UE initiates an RRC connection reconstruction process to restore the RRC connection (i.e., the MCG connection or link).

[0302] - For SCG, a supervisory timer can be used to detect the failure of the LTM cell handover process. If the LTM supervisory timer expires, the LTM process fails. At this time, the UE initiates an SCG failure information process to report the SCG failure to the network.

[0303] When the UE has already stored the LTM candidate cell configuration, the UE can also execute any L3 handover command sent by the network. The network should avoid any problems caused by conflicts between LTM execution and L3 handover execution, such as avoiding sending LTM cell handover commands and L3 handover commands simultaneously.

[0304] The following pertains to LTM execution failure handling. When an LTM execution failure is detected by the expiration of a custodian timer or by RLF (Radio Link Failure) or BFD (Beam Failure Detection) (i.e., LTM execution has failed), the UE can report the LTM execution failure in an RRC message to the source serving cell (Pcell) or the target serving cell (after LTM execution to the new target serving cell has been completed later, for example, for SON (Self-Organizing Network) or MDT (Minimized Drive Test) purposes). In another embodiment, the UE can report the LTM execution failure via the SCell (or source cell) if the SCell is configured with a different TAG than the PCell, or if the SCell's TAT ​​is active (or the cell's TA is valid), or if it has both UL (Uplink) and DL (Downlink), or if it has a PUCCH configured or activated, or if it has an SSB in its activated BWP. In another embodiment, when an LTM execution failure is detected by the expiration of a custodian timer or by an RLF (Radio Link Failure) or BFD (Beam Failure Detection), if the cell is configured with a different TAG than the PCell, or has both UL (Uplink) and DL (Downlink), or is configured with a PUCCH, or is activated, or has an SSB in its activated BWP, or if the cell's TAT ​​is active (or the cell's TA is valid), or if an attempt to a new target LTM cell is configured in the RRC configuration (or a second LTM execution after the first LTM execution failure), the UE may execute (or re-initiate or attempt) an LTM execution to a candidate LTM cell (or SCell). This can be performed by the UE automatically performing cell reselection, or it can be performed based on an RRC configuration that includes a new target LTM candidate cell identifier (e.g., a configuration identifier) ​​to be used for LTM execution failure cases, or it can be indicated by a MAC CE that includes a new target LTM candidate cell identifier (e.g., a configuration identifier). When an LTM execution failure is detected by the expiration of the custodian timer, RLF (Radio Link Failure), or BFD (Beam Failure Detection), the UE can initiate an RRC connection reconstruction procedure (e.g., including cell (re)selection) to restore the RRC connection if any LTM candidate cell's TAT ​​is not running, or if any LTM candidate cell's TA is invalid, or if there is no attempt to configure a new target LTM cell in the RRC configuration (or in a second LTM execution after the first LTM execution failure). Based on this, the behavior of the custodian timer can be extended as follows: - LTM policing timers (e.g., Txx timers) can be managed for each cell group (e.g., MCG or SCG) in the RRC layer.

[0305] - The UE starts an LTM surveillance timer when it receives an LTM cell handover MAC CE. The UE can restart the LTM surveillance timer when it receives an LTM cell handover MAC CE indicating subsequent LTM. For example, the UE can start or restart the LTM surveillance timer when it receives an LTM cell handover MAC CE.

[0306] - The UE stops the LTM supervisory timer when it successfully completes an LTM cell handover, or when it detects a beam failure (i.e., if BFI_COUNTER >= beamFailureInstanceMaxCount of the target / indicated LTM candidate cell (or PTAG or serving cell or target cell), or when it receives an RRCReconfiguration including reconfigurationWithSync, or when it detects an RLF.

[0307] - For MCG, a custodian timer can be used to detect failures in the LTM cell handover process, where the LTM process fails if the LTM custodian timer expires. When an LTM execution failure is detected by the custodian timer expiration or by RLF (Radio Link Failure) or BFD (Beam Failure Detection) (i.e., LTM execution has failed), the UE can initiate an RRC connection reconstruction process (e.g., including cell (re)selection) to restore the RRC connection if the TAT of any LTM candidate cell is not running, or if the TA of any LTM candidate cell is invalid, or if there is no attempt to configure a new target LTM cell in the RRC configuration (or in a second LTM execution after the first LTM execution failure).

[0308] - For SCG, a supervisory timer can be used to detect the failure of the LTM cell handover process. If the LTM supervisory timer expires, the LTM process fails. At this time, the UE initiates an SCG failure information process to report the SCG failure to the network.

[0309] - In another embodiment, for SCG, a supervisory timer can be used to detect failures in the LTM cell handover process, wherein the LTM process fails if the LTM supervisory timer expires. When an LTM execution failure is detected by the expiration of the supervisory timer or by RLF (Radio Link Failure) or BFD (Beam Failure Detection) (i.e., LTM execution has failed), the UE initiates an SCG failure information procedure to report the SCG failure to the network if the TAT of any LTM candidate cell is not running, or if the TA of any LTM candidate cell is invalid, or if there is no attempt to configure a new target LTM cell in the RRC configuration (or in a second LTM execution after the first LTM execution failure).

[0310] In another embodiment, when an LTM execution failure is detected by the expiration of a regulated timer or by RLF (Radio Link Failure) or BFD (Beam Failure Detection) (i.e., LTM execution has failed), if the cell is configured with a different TAG than the PCell or has both UL (Uplink) and DL (Downlink) or is configured with PUCCH or is activated or has SSB in its activated BWP, or if the cell's TAT ​​is active (or the cell's TA is valid), or if an attempt to a new target LTM cell is configured in the RRC configuration (or a second LTM execution after the first LTM execution failure), the UE can perform (or re-initiate or attempt) LTM execution to the cell of the candidate LTM cell (or SCell) using a no-RACH scheme. This can be performed by the UE automatically performing cell reselection, or it can be performed based on an RRC configuration that includes a new target LTM candidate cell identifier (e.g., a configuration identifier) ​​to be used for LTM execution failure, or it can be indicated by a MAC CE that includes a new target LTM candidate cell identifier (e.g., a configuration identifier). When an LTM execution failure is detected by the expiration of a custodian timer, RLF (Radio Link Failure), or BFD (Beam Failure Detection), if the cell is configured with a different TAG than the PCell, or has both UL (Uplink) and DL (Downlink), or is configured with a PUCCH, or is activated, or has an SSB in its activated BWP, or if the cell's TAT ​​is not running (or the cell's TA is invalid), or if an attempt to reach a new target LTM cell is configured in the RRC configuration (or a second LTM execution after the first LTM execution failure), the UE may perform (or re-initiate or attempt) an LTM execution to a candidate LTM cell (or SCell) using a random access procedure. This can be performed by the UE automatically performing cell reselection, or it can be performed based on an RRC configuration that includes the identifier of the new target LTM candidate cell (e.g., a configuration identifier) ​​to be used in the LTM execution failure case, or it can be indicated by a MAC CE that includes the identifier of the new target LTM candidate cell (e.g., a configuration identifier). This can be applied to the MCG or SCG.

[0311] In addition, when an LTM execution failure is detected by the expiration of the custodian timer, RLF (Radio Link Failure), or BFD (Beam Failure Detection), if the TAT (Target Attack) of any LTM candidate cell is not running, or if the TA (Target Attack) of any LTM candidate cell is invalid, or if there is no attempt to configure a new target LTM cell in the RRC configuration (or in a second LTM execution after the first LTM execution failure), the UE can initiate an RRC connection reconstruction procedure (e.g., including cell (re)selection) to restore the RRC connection. Based on this, the behavior of the proposed custodian timer can be extended as follows: - For MCG, a custodian timer can be used to detect failures in the LTM cell handover process, where the LTM process fails if the LTM custodian timer expires. When an LTM execution failure is detected by the custodian timer expiration or by RLF (Radio Link Failure) or BFD (Beam Failure Detection) (i.e., LTM execution has failed), the UE can initiate an RRC connection reconstruction process (e.g., including cell (re)selection) to restore the RRC connection (i.e., MCG connection or link) if the TAT of any LTM candidate cell is not running, or if the TA of any LTM candidate cell is invalid, or if there is no attempt to configure a new target LTM cell in the RRC configuration (or in a second LTM execution after the first LTM execution failure).

[0312] - For SCG, a supervisory timer can be used to detect the failure of the LTM cell handover process. If the LTM supervisory timer expires, the LTM process fails. At this time, the UE initiates an SCG failure information process to report the SCG failure to the network.

[0313] - In another embodiment, for SCG, a supervisory timer can be used to detect failures in the LTM cell handover process, wherein the LTM process fails if the LTM supervisory timer expires. When an LTM execution failure is detected by the expiration of the supervisory timer or by RLF (Radio Link Failure) or BFD (Beam Failure Detection) (i.e., LTM execution has failed), the UE initiates an SCG failure information procedure to report the SCG failure to the network if the TAT of any LTM candidate cell is not running, or if the TA of any LTM candidate cell is invalid, or if there is no attempt to configure a new target LTM cell in the RRC configuration (or in a second LTM execution after the first LTM execution failure).

[0314] To avoid unnecessary network confusion, LTM execution failures should be handled carefully, as RRC messages for failed target LTM candidate cells may be retransmitted to new target candidate cells. Specifically, upon receiving the first MAC CE or when the LTM execution process is initiated, the UE generates message 3 (e.g., an RRCReconfigurationComplete message) and sends it to the target LTM candidate cell via SRB1 during the LTM execution process. When the LTM execution process fails (e.g., random access problems, policing timer expiration, beam failure detection, or radio link failure), the RRC message for the target LTM candidate cell can be retained in the RLC or PDCP entity of SRB1 and retransmitted later to the new target LTM candidate cell if a subsequent LTM cell handover is triggered. This can cause problems because the RRC message was generated for the previous target LTM candidate cell. To address this issue, this application proposes that if LTM execution fails, the UE should execute the PDCP SDU discarding procedure of SRB1 or rebuild the RLC entity of SRB1 to avoid unnecessary retransmission of RRC messages to an unexpected target cell. This can be triggered by the RRC layer, by the expiration of a custodian timer, by receiving the first MAC CE (e.g., containing the configuration ID of the new target LTM candidate cell), or by initiating the LTM execution procedure (e.g., to a new target cell). PDCP SDU discarding is an SDU discarding procedure whereby the PDCP entity should discard all stored PDCP SDUs and PDCP PDUs, or the sending PDCP entity should discard PDCP SDUs and corresponding PDCP data PDUs. It may also include the discarding of RRC message segments. If the corresponding PDCP data PDU has already been submitted to a lower layer, the discarding is indicated to the lower layer (e.g., when an upper layer requests PDCP SDU discarding). In another embodiment, when LTM execution fails, or when the custodian timer expires or a first MAC CE (e.g., including the configuration ID of a new target LTM candidate cell) is received, or when an LTM execution procedure is initiated (e.g., to a new target cell), the PDCP entity (i.e., the PDCP entity of the UE's SRB (e.g., SRB1)) will discard all stored PDCP SDUs and PDCP PDUs, or rebuild the RLC entity (i.e., the RLC entity of the UE's SRB (e.g., SRB1)). The rebuilding of the RLC entity includes the following actions: discarding all RLC SDUs, RLC SDU segments, and RLC PDUs (if any), stopping and resetting all timers, and resetting all state variables to their initial values.

[0315] The following addresses security issues related to LTM execution failures. LTM execution failures can be handled as described above. However, if subsequent LTM executions are allowed to quickly recover from a failure when the LTM execution process fails, security issues may arise (e.g., key stream reuse issues), which violate security principles (i.e., different data should not be sent using the same security key over the air interface). It is important to note that the security key (or security configuration or masterKeyUpdate) is not configured (or not updated) in the LTM candidate cell configuration.

[0316] For example, as described in Section 3.3, the UE can send an RRCReconfigurationComplete message to the target LTM candidate cell via SRB1 during an LTM execution procedure (e.g., upon receiving the first MAC CE). If the UE fails to successfully send it to the target LTM candidate cell via SRB1, the UE can perform another LTM execution procedure to the new target LTM candidate cell by receiving another first MAC CE. In this case, when the UE reverts to the UE configuration used in the source PCell (or serving cell), it may send another RRCReconfigurationComplete message to the new target LTM candidate cell using the same security key (or the same COUNT value). Messages using the same security key mean that the message is protected for integrity or encrypted with the same security key (or the same security algorithm). For example, the UE can send an RRCReconfigurationComplete message to the target LTM candidate cell via SRB1 using the security key (or COUNT value = 3). After the UE fails to send it to the target candidate cell, the UE reverts to the UE configuration used in the source PCell (e.g., the COUNT value is set to 2). When LTM execution is triggered again for a new target LTM candidate cell, the UE may send another RRCReconfigurationComplete message to the target LTM candidate cell via SRB1 using the same security key (or the same COUNT value = 3), which violates security principles and may expose the UE to hackers. To address this security issue, this application proposes several options below. One of these options can be implemented to handle the security problem (it can be applied to the SRB).

[0317] Option 1. In this option, the UE can use a single SRB, i.e., an SRB (e.g., first SRB1), for either the source cell (i.e., the serving cell) or the target cell. First SRB1 can be used to send RRC messages to and receive RRC messages from the source cell. Upon receiving the first MAC CE or when an LTM execution procedure is initiated, the UE rebuilds the RLC entity of first SRB1 or triggers the PDCP entity of first SRB1 to perform the SDU discard procedure. During LTM execution, the UE can send an RRCReconfigurationComplete message to the target LTM candidate cell via first SRB1. When the UE fails to perform an LTM cell handover to the target LTM candidate cell (or the custodian timer expires), or upon receiving the first MAC CE, or when another LTM execution is initiated, the UE rebuilds the RLC entity of first SRB1 or triggers the PDCP entity of first SRB1 to perform the SDU discard procedure to avoid unnecessary retransmissions and network confusion caused by unexpected RRC messages. During LTM execution, the UE can send an RRCReconfigurationComplete message to the new target LTM candidate cell via the first SRB1. In this option, the network can handle the gaps between PDCP sequence numbers (or COUNT values) to avoid unnecessary delays (e.g., performing out-of-order delivery but executing in ascending order). When the UE fails to perform an LTM cell handover to the target LTM candidate cell (or the custodian timer expires), the UE can revert to the UE configuration used in the source PCell. In another embodiment, when the UE fails to perform an LTM cell handover to the target LTM candidate cell (or the custodian timer expires), the UE can revert to a UE configuration other than the SRB configuration (e.g., SRB or SRB1) used in the source PCell.

[0318] Option 2. In this option, the UE can use two SRBs: one SRB (e.g., first SRB1) for the source cell (i.e., the serving cell), and another SRB (e.g., second SRB1) for the target cell. First SRB1 can be used to send RRC messages to and receive RRC messages from the source cell. Upon receiving the first MAC CE or when the LTM execution procedure is initiated, the UE suspends first SRB1, or establishes second SRB1 (i.e., logical channel identifier, RLC entity, or PDCP entity) using the same configuration as the source cell, or configures the PDCP entity of second SRB1 for the target LTM candidate cell using continuous state variables and the same security configuration as the PDCP entity of the source cell. For second SRB1 configured with continuous state variables, the initial value is the value stored in the PDCP entity of the corresponding first SRB1. During LTM execution, the UE can send an RRCReconfigurationComplete message to the target LTM candidate cell via second SRB1. When a UE fails to perform an LTM cell handover to a target LTM candidate cell (or the custodian timer expires), the UE uses state variable continuity to configure the PDCP entity of the first SRB1 for the source PCell. For a first SRB1 configured with state variable continuity, the initial value is the value stored in the PDCP entity of the corresponding second SRB1. The UE releases the PDCP entity of the target PCell, or releases the RLC entity and associated logical channel of the target LTM candidate cell, or triggers the PDCP entity of the first SRB1 of the source cell (e.g., PCell) to perform an SDU drop procedure or rebuild the RLC entity of the first SRB1 of the source cell (e.g., PCell). The UE resumes the suspended first SRB1 in the source cell. The UE can report the failure of LTM execution to the network by sending an RRC message indicating LTM execution failure or a MAC CE. The network then instructs the UE on subsequent LTM cell handover procedures. When a UE fails to perform an LTM cell handover to a target LTM candidate cell (or the custodian timer expires), the UE can revert to the UE configuration used in the source PCell. In another embodiment, when the UE fails to perform an LTM cell handover to the target LTM candidate cell (or the custodian timer expires), the UE can revert to a UE configuration other than the SRB configuration (e.g., SRB or SRB1) used in the source PCell.

[0319] Option 3. In this option, the UE can use two SRBs: one SRB (e.g., the first SRB1) for the source cell (i.e., the serving cell), and another SRB (e.g., the second SRB1 or the third SRB1) for the target cell. The first SRB1 can be used to send RRC messages to and receive RRC messages from the source cell. Upon receiving the first MAC CE or when the LTM execution procedure is initiated, the UE suspends the first SRB1, or establishes the second SRB1 (i.e., logical channel identifier, RLC entity, or PDCP entity) using the same configuration as the source cell, or configures the PDCP entity of the second SRB1 for the target LTM candidate cell using continuous state variables and the same security configuration as the PDCP entity of the source cell. For the second SRB1 configured with continuous state variables, the initial value is the value stored in the PDCP entity of the corresponding first SRB1. During LTM execution, the UE can send an RRCReconfigurationComplete message to the target LTM candidate cell via the second SRB1. When a UE fails to perform an LTM cell handover to a target LTM candidate cell (or the custodian timer expires), or upon receiving the first MAC CE, or when initiating another LTM execution, the UE rebuilds the third SRB1 for the new target LTM candidate cell, or continuously configures the PDCP entity of the third SRB1 for the new target LTM candidate cell (e.g., PCell) using state variables. For a third SRB1 configured with continuous state variables, the initial value is the value stored in the PDCP entity of the corresponding second SRB1. The UE releases the PDCP entity of the old target PCell or releases the RLC entity and associated logical channel of the old target LTM candidate cell. During LTM execution, the UE can send an RRCReconfigurationComplete message to the new target LTM candidate cell via the third SRB1. When a UE fails to perform an LTM cell handover to a target LTM candidate cell (or the custodian timer expires), the UE can restore the UE configuration used in the source PCell. In another embodiment, when the UE fails to perform an LTM cell handover to the target LTM candidate cell (or the custodian timer expires), the UE can revert to a UE configuration other than the SRB configuration (e.g., SRB or SRB1) used in the source PCell.

[0320] The following describes data loss handling for LTM execution failures. During LTM execution, the UE may perform a random access procedure to send an RRCReconfigurationComplete message to the target candidate cell. There are two types of random access procedures.

[0321] Figure 11Various random access procedures according to embodiments of this disclosure are illustrated.

[0322] Two types of random access procedures are supported: a 4-step RA type with MSG1 and a 2-step RA type with MSGA. Both types of RA procedures support contention-based random access (CBRA) and contention-free random access (CFRA), such as... Figure 11 As shown.

[0323] When initiating a random access procedure, the UE selects the type of random access based on network configuration: -When no CFRA resource is configured, the UE uses the RSRP threshold to select the 2-step RA type and the 4-step RA type; - When CFRA resources for 4-step RA type are configured, the UE performs random access with 4-step RA type; - When CFRA resources for 2-step RA type are configured, the UE performs random access with 2-step RA type.

[0324] For the Bandwidth Part (BWP), the network does not simultaneously configure CFRA resources for both 4-step RA type and 2-step RA type. CFRA with 2-step RA type is only supported for handover.

[0325] In step 4, the MSG1 of the RA type consists of a preamble on the PRACH. After the MSG1 transmission, the UE monitors for responses from the network within a configured window. For CFRA, a dedicated preamble for MSG1 transmission is assigned by the network, and the UE terminates the random access procedure upon receiving a random access response from the network, as shown below. Figure 11 As shown in section (c). For CBRA, upon receiving a random access response, the UE uses the UL grant scheduled in the response to send MSG3 and monitors contention resolution, as... Figure 11 As shown in part (a). If contention resolution fails after MSG3 (re)transmission, the UE returns to MSG1 transmission.

[0326] Figure 12 A fallback of a CBRA of type 2-step RA according to an embodiment of this disclosure is shown.

[0327] The 2-step RA type MSGA includes a preamble on the PRACH and a payload on the PUSCH. After the MSGA transmission, the UE monitors for a response from the network within a configured window. For CFRA, dedicated preamble and PUSCH resources are configured for MSGA transmission, and upon receiving a network response, the UE terminates the random access procedure, as follows. Figure 11As shown in part (d). For CBRA, if contention resolution is successful upon receiving a network response, the UE terminates the random access procedure, as... Figure 11 As shown in part (b). If a fallback indication is received in the MSGB, the UE uses the UL grant scheduled in the fallback indication to perform the MSG3 transmission and monitors for contention solutions, such as... Figure 12 As shown. If contention resolution fails after MSG3 (re)transmission, the UE returns to MSGA transmission.

[0328] If a random access procedure of type 2 RA is not completed after multiple MSGA transmissions, the UE can be configured to switch to CBRA of type 4 RA.

[0329] During this random access procedure, user plane data (data from the DRB) may be transmitted (e.g., in MSG 3 or MSG A). This means that if the random access procedure fails during LTM execution, data loss may occur. Given that subsequent LTM executions are possible, data loss may occur several times. To avoid potential data loss during LTM execution, this application proposes the following options. One of these options can be implemented to address this problem.

[0330] Option 1: CFRA does not include user plane data before the random access procedure is completed because MSG1 is first confirmed by the network before data transmission. Therefore, in this option, if a random access procedure is required during LTM execution, the UE performs CFRA; that is, the UE is not allowed to perform CBRA during LTM execution.

[0331] Option 2: CFRA does not include user plane data before the random access procedure is completed because MSG1 is first acknowledged by the network before data transmission. Therefore, in this option, the UE is not allowed to include or transmit user plane data when performing CFRA during LTM execution. For example, for resource allocation in the LCP (Logical Channel Priority) procedure, the MAC entity should not select the logical channel corresponding to the DRB for the uplink grant received in the random access response or for the uplink grant for MSGA payload transmission before the random access procedure initiated for LTM cell handover (or LTM execution) is successfully completed. This means that the UE can only submit RRC messages (e.g., RRCReconfigurationComplete message) during the random access procedure during LTM execution. This also means that user plane data is not included in MSG 3 or MSG A (i.e., MACPDU) during the random access procedure. In another embodiment, the UE may suspend all radio bearers (i.e., DRBs) except for SRBs (e.g., SRB0, SRB1, SRB2, SRB3, SRB4, or SRB5) to avoid data processing or data transmission (or reception) of the source cell, or to avoid data transmission during random access to the target cell. After successfully completing LTM execution (or LTM cell handover to the target cell), the UE may resume all suspended radio bearers except for SRBs to begin data transmission or reception.

[0332] The following pertains to the MAC protocol.

[0333] MAC control element (MAC CE)

[0334] The first MAC CE is an LTM-triggered MAC CE that triggers a cell handover to the target cell (i.e., one of the LTM candidate cells configured by the RRCReconfiguration message).

[0335] The content of an LTM-triggered MAC CE (or LTM command MAC CE or LTM MAC CE) may include one of the following information: -CFRA Resources -LTM candidate cell configuration index (or identifier) ​​or cell identifier -Community signage -TCI status or beam information (e.g., beam index, SSB index, etc.) - Timing advance value (TA value or timing advance command) Specifically, the first MAC CE (i.e., the LTM command MAC CE) is identified by a MAC subheader with eLCID. It is variable in size and has one or more of the following fields: -R: Reserved bits, set to 0; - Target Configuration ID (Identifier) ​​(or Target LTM Candidate Cell Identifier (i.e., LTM Target Cell) or Serving Cell Identifier): This field indicates the index (or identifier) ​​of the target LTM candidate cell configuration (in the RRC configuration) to be applied to the LTM cell handover. This field may be replaced by a bitmap in the PDCCH DCI format proposed in this disclosure (Section 4.2) to indicate the target LTM candidate cell.

[0336] - Pre-time command: To enable the UE to implement efficient or resource-saving radio commands, this application proposes several options for this field. One of the options can be implemented.

[0337] - Option 1: In this option, the timing advance command field (or value) is optional in the first MAC CE (LTM command MAC CE), which saves radio resources. This field indicates the value of the timing adjustment amount that the control MAC entity must apply (or it may indicate the use of the same TA value of the currently serving cell). If this field indicates a value (i.e., this field is present or included), or if the TAT (timeAlignmentTimer) of the target / indicated LTM candidate cell (or PTAG) is running (i.e., the TA value is valid), or if no beam failure is detected in the target LTM candidate cell (i.e., BFI_COUNTER < beamFailureInstanceMaxCount of the target / indicated LTM candidate cell (the number of beam failure indications is less than the maximum number used for beam failure detection)), the UE can skip the random access procedure for handover to that LTM cell. If the time advance command value is missing (or not included or does not exist), or the TAT (timeAlignmentTimer) of the target / indicated LTM candidate cell (or PTAG) is not running (i.e., the TA value is invalid), or a beam failure is detected for the target / indicated LTM candidate cell (i.e., BFI_COUNTER >= beamFailureInstanceMaxCount of the target / indicated LTM candidate cell (or PTAG) (the number of beam failure indications is greater than or equal to the maximum number used for beam failure detection)).

[0338] Option 2: In this option, the Timing Advance Command (TA) field (or value) is always present in the first MAC CE (LTM Command MAC CE), which simplifies UE implementation. This field indicates whether the TA is valid for the LTM target cell (i.e., the LTM candidate cell corresponding to the LTM candidate cell configuration (RRC configuration) indicated by the Target Configuration ID field) (or whether the same TA value of the current serving cell is used). If the value of this field is set to a specific value (e.g., all 0s or all 1s), this field indicates that no valid timing adjustment is available for the PTAG of the LTM target cell. If the value of this field is set to a specific value (e.g., all 0s or all 1s), the UE should perform random access to the LTM target cell. Otherwise, this field indicates the value of the timing adjustment amount that the control MAC entity must apply. If this field indicates a value (i.e., this field does not indicate a specific value), or if the TAT (timeAlignmentTimer) of the target / indicated LTM candidate cell (or PTAG) is running (i.e., the TA value is valid), or if no beam failure is detected in the target LTM candidate cell (i.e., BFI_COUNTER < beamFailureInstanceMaxCount of the target / indicated LTM candidate cell (the number of beam failure indications is less than the maximum number used for beam failure detection)), then the UE can skip the random access procedure for handover to that LTM cell.

[0339] -TCI State ID: This field indicates or activates the TCI state for the LTM target cell (i.e., the cell (SpCell) of the target LTM candidate configuration indicated by the Target Configuration ID field). The TCI state is identified by the TCI-StateId configured in the target LTM candidate configuration. If this field is missing (or does not exist or is not included), the default TCI state (or TCI state) configured in the target LTM candidate configuration is used or activated. This field can be replaced or omitted by using a fourth MAC CE; that is, in another embodiment, this field can be indicated / included in the fourth MAC CE.

[0340] -UL TCI State ID: This field indicates or activates the uplink TCI state for the LTM target cell (i.e., the cell (i.e., SpCell) of the target LTM candidate configuration indicated by the Target Configuration ID field). If this field is missing (or does not exist or is not included), the default TCI state (or TCI state) configured in the target LTM candidate configuration is used or activated. This field can be replaced or omitted by using a fourth MAC CE; that is, in another embodiment, this field can be indicated / included in the fourth MAC CE.

[0341] -DL BWP ID: This field indicates the DL BWP used by the UE for the target LTM cell. If this field is present (or included), the MAC entity (or UE) activates the DL BWP indicated by this field for LTM execution or LTM cell handover. If this field is missing (absent or not included), the MAC entity (or UE) activates the DL BWP indicated by the RRC configuration (i.e., the firstActiveDownlinkBWP-Id in the target LTM candidate configuration indicated by the target configuration ID) for LTM execution or LTM cell handover. In another embodiment, a common BWP ID (or the same BWP ID) may indicate both the DL BWP ID and the UL BWPID, or the BWP ID may be indicated / included in the fourth MAC CE.

[0342] -UL BWP ID: This field indicates the UL BWP used by the UE for the target LTM cell. If this field is present (or included), the MAC entity (or UE) activates the UL BWP indicated by this field for LTM execution or LTM cell handover. If this field is missing (absent or not included), the MAC entity (or UE) activates the UL BWP indicated by the RRC configuration (i.e., the firstActiveUplinkBWP-Id in the target LTM candidate configuration indicated by the target configuration ID) for LTM execution or LTM cell handover. In another embodiment, a common BWP ID (or the same BWP ID) may indicate both the DL BWP ID and the UL BWP ID, or the BWP ID may be indicated / included in the fourth MAC CE.

[0343] The fields in the first MAC CE, excluding the target configuration ID, refer to the RRC configuration (target LTM candidate configuration) indicated by the target configuration ID field. That is, these fields are considered (or processed) after the UE has applied the complete (or referenced) LTM candidate configuration indicated by the target configuration ID in the first MAC CE. It does not refer to the RRC configuration used before / at the time the MAC CE is received.

[0344] To select a BWP (Bandwidth Part) during LTM cell handover, the UE needs to identify the UL BWP of the LTM candidate cell used for random access preamble transmission (on PRACH or RACH). Since LTM candidate cells are non-serving cells, and there are no active UL or DL ​​BWPs for non-serving cells, the UE needs to identify which UL BWP it will use for random access preamble transmission. For this purpose, the UE uses…

[0345] - If the first MAC CE includes a BWP ID (e.g., a UL BWP ID), the UE uses the UL BWP indicated by the BWP ID field in the first MAC CE received by the UE. The BWP ID is not configured to have the same ID as the dormant BWP (i.e., dormantBWP-Id).

[0346] - If the first MAC CE does not include a BWP ID (e.g., a UL BWP ID), the UE uses the UL BWP indicated by the firstActiveUplinkBWP field in the configuration of the indicated target LTM candidate cell. The BWP ID is not configured to have the same ID as the dormant BWP (i.e., dormantBWP-Id), or the LTM candidate cell configuration does not include a dormant BWP configuration (i.e., dormantBWP-Config). In another embodiment, the initialUplinkBWP field can be used instead of the firstActiveUplinkBWP field.

[0347] - If the first MAC CE includes a BWP ID (e.g., DL BWP ID), the UE uses the DL BWP indicated by the BWP ID field in the first MAC CE received by the UE. The BWP ID is not configured to have the same ID as the dormant BWP (i.e., dormantBWP-Id).

[0348] - If the first MAC CE does not include a BWP ID (e.g., a DL BWP ID), the UE uses the DL BWP indicated by the firstActiveDownlinkBWP field in the configuration of the indicated target LTM candidate cell. The BWP ID is not configured to have the same ID as the dormant BWP (i.e., dormantBWP-Id), or the LTM candidate cell configuration does not include a dormant BWP configuration (i.e., dormantBWP-Config). In another embodiment, the initialDownlinkBWP field can be used instead of the firstActiveUplinkBWP field.

[0349] A dormant BWP should not be configured for LTM candidate cells because LTM procedures (e.g., random access procedures and LTM cell handover) require PDCCH monitoring.

[0350] The first MAC CE (i.e., the LTM command MAC CE) may include a field indicating information about contention-free random access resources for 2-step RA type and 4-step RA type used for LTM cell handover execution. This field may be present if the timing advance command value is missing (or not included), or if it does not indicate maintaining timing advance or using the timing advance of the source cell (or serving cell) (i.e., the LTM candidate cell indicated by the target configuration ID (or serving cell ID) in the first MAC CE does not belong to the PTAG), or if the timing advance command value is set to a special value (e.g., 000..0 or 111…1) (e.g., this value indicates LTM candidate cell handover based on RACH), or if a random access procedure is required.

[0351] If a field included in the first MAC CE (e.g., target configuration ID, BWP ID, TCI status ID, or timing advance) is introduced as a bitmap type indicator (e.g., an 8-bit bitmap), then the bitmap (i.e., each bit or the (k)th bit) can indicate field k (or target configuration ID k, BWP ID k, TCI status ID k, or timing advance k), where k is an ascending (or descending) order of the field value (or ID) associated with the MAC entity (or the cell group) receiving the first MAC CE, which can save bits in the air interface.

[0352] In another embodiment, if a field included in the first MAC CE (e.g., target configuration ID, BWP ID, TCI status ID, or timing advance) is introduced as a bitmap type indicator (e.g., an 8-bit bitmap), then the bitmap (i.e., each bit or the (k)th bit) can indicate field k (or target configuration ID k, BWP ID k, TCI status ID k, or timing advance k), where k is an ascending (or descending) order of field values ​​(or IDs) in the order of MCG and SCG (i.e., MCG fields first, then SCG fields). This can save bits in the air interface; that is, the first MAC CE can indicate the target configuration ID, BWP ID, TCI status ID, or timing advance of the MCG or SCG. For example, the first MAC CE received from the MCG (i.e., associated with the MCG MAC entity) can indicate the field corresponding to the SCG, or the first MAC CE received from the SCG (i.e., associated with the SCG MAC entity) can indicate the field corresponding to the MCG.

[0353] Figure 13 An octet of the SCell activation / deactivation MAC CE according to an embodiment of the present disclosure is shown.

[0354] The second MAC CE is SCell activation / deactivation of MAC CE.

[0355] An octet SCell activation / deactivation MAC CE is identified by a MAC subheader with an LCID. It is of fixed size and consists of a single octet containing seven C fields and one R field. The definition of an octet SCell activation / deactivation MAC CE is as follows ( Figure 13 ).

[0356] Figure 14 The illustration shows a SCell activation / deactivation MAC CE with four octets according to an embodiment of this disclosure.

[0357] The four-octet SCell activation / deactivation MAC CE is identified by a MAC subheader with an LCID. It is of fixed size and consists of four octets containing 31 C fields and one R field. The four-octet SCell activation / deactivation MAC CE is defined as follows ( Figure 14 ).

[0358] -Ci: If a SCell with SCellIndex i configured for the MAC entity exists, this field indicates the activation / deactivation status of the SCell with SCellIndex i; otherwise, the MAC entity ignores this Ci field. A Ci field set to 1 indicates that the SCell with SCellIndex i should be activated. A Ci field set to 0 indicates that the SCell with SCellIndex i should be deactivated. -R: Reserved bit, set to 0.

[0359] Note: If the UE receives a SCell activation / deactivation MAC CE for a SCell that is configured with a TRS for fast SCell activation, then the TRS is not used for the corresponding SCell.

[0360] The third MAC CE is an enhanced SCell activation / deactivation MAC CE.

[0361] An enhanced SCell activation / deactivation MAC CE with an octet Ci field is identified by a MAC subheader with an eLCID. It is variable in size and consists of seven C fields, one R field, and zero or more TRS IDj fields arranged in ascending order based on the ScellIndex of the SCell to be activated, as indicated by the Ci field. The enhanced SCell activation / deactivation MAC CE with an octet Ci field is defined as follows ( Figure 14 ).

[0362] Figure 15An enhanced SCell activation / deactivation MAC CE with an octet Ci field is illustrated according to an embodiment of this disclosure.

[0363] An enhanced SCell activation / deactivation MAC CE with four octet Ci fields is identified by a MAC subheader with eLCID. It has a variable size and consists of 31 C fields, one R field, and zero or more TRS IDj fields arranged in ascending order based on the ScellIndex of the SCell to be activated, as indicated by the Ci fields. The enhanced SCell activation / deactivation MAC CE with four octet Ci fields is defined as follows ( Figure 15 ).

[0364] -Ci: If a SCell with SCellIndex i configured for the MAC entity exists, this field indicates the activation / deactivation status of the SCell with SCellIndex i; otherwise, the MAC entity ignores this Ci field. A Ci field set to 1 indicates that the SCell with SCellIndex i should be activated and includes the TRS IDj field for that SCell. A Ci field set to 0 indicates that the SCell with SCellIndex i should be deactivated and does not include the TRS IDj field for that SCell. -TRS IDj: If TRS IDj is set to a non-zero value, it indicates that the TRS address corresponding to the scellActivationRS-Id configured in the RRC message is activated. If TRS IDj is set to zero, it indicates that no TRS is used for the corresponding SCell; -R: Reserved bit, set to 0.

[0365] For the first, second, and third MAC CEs, rules and restrictions are expected to simplify and improve the efficiency of UE behavior during LTM cell handover. As mentioned above, LTM supports mobility within and between gNB-DUs, as well as between gNB-DUs. LTM also supports inter-frequency mobility, including mobility to inter-frequency cells that are not the current serving cell. The following scenarios are supported: - PCell changes in non-CA scenarios In a CA scenario, PCell changes while SCell remains unchanged. - Changes to PCell and SCell in CA scenarios include the following: a) The target PCell / target SCell is not the current serving cell (CA-to-CA scenario with PCell change). b) The target PCell is the current SCell c) The target SCell is the current PCell.

[0366] To efficiently support these scenarios, it may be necessary to define some rules and restrictions for MAC CE, as some scenarios increase the complexity of UE implementation. For example, the current PCell may be instructed to hand over to one of the current SCells in an LTM cell and to activate / deactivate the SCell, which could be a race condition.

[0367] Option 1. In this option, the network should not send the first MAC CE together with the second MAC CE (or the third MAC CE) to the UE. In other words, the network should not include the first MAC CE and the second MAC CE (or the third MAC CE) in the same MAC PDU. By having this restriction, the network can send commands cascadingly. For example, - Operation 1: The network can configure LTM candidate cell configuration to the UE via RRC messages. The network can activate, deactivate, configure (add / modify), or release SCells via RRC messages, a second MAC CE, or a third MAC CE to prepare SCells for LTM cell handover by activating / deactivating SCells. This can be done simultaneously through LTM candidate cell configuration, i.e., via RRC messages or MAC CE.

[0368] - Operation 2: The network can send the first MAC CE to the UE to trigger LTM cell handover to the target cell.

[0369] - Operation 3: The network may send a second MAC CE or a third MAC CE to the UE to activate or deactivate the SCell (e.g., after a successful LTM cell handover, or when the conditions set forth in Section 2.1 are met).

[0370] Option 2. In this option, the network can send the first MAC CE together with the second (or third) MAC CE to the UE. In other words, the network can include the first and second MAC CEs (or the third MAC CE) in the same MAC PDU. By allowing this operation, the network can send commands (LTM cell handover and SCell activation / deactivation) together, which can reduce latency. For example, - Operation 1: The network can configure LTM candidate cell configuration to the UE via RRC messages. The network can activate, deactivate, configure (add / modify), or release SCells via RRC messages, a second MAC CE, or a third MAC CE to prepare SCells for LTM cell handover by activating / deactivating them. This can be accomplished simultaneously through LTM candidate cell configuration, i.e., via RRC messages or MAC CEs. It can also be accomplished by including a first MAC CE and a second MAC CE (or a third MAC CE) in the same MAC PDU in Operation 2.

[0371] - Operation 2: The network can send the first MAC CE to the UE to trigger LTM cell handover to the target cell. Alternatively, the network can send the first MAC CE and the second MAC CE (or the third MAC CE) together to the UE in the same MAC PDU to trigger LTM cell handover and SCell activation / deactivation.

[0372] To facilitate UE implementation, the UE can automatically deactivate or deconfigure the SCell upon receiving the first MAC CE (or during LTM execution), upon receiving an RRC reconfiguration including an LTM candidate configuration, or upon / after applying the target LTM candidate configuration. In another embodiment, the UE can activate, deactivate, deconfigure, or configure the SCell based on the target LTM candidate configuration used in the LTM execution process (or via a second (or third) MAC CE), meaning the network can determine the SCell's state via RRC messages or MAC CEs. In yet another embodiment, the UE can automatically deactivate or configure the SCell belonging to the PTAG (i.e., the SCell with the same TA value as the SpCell (serving cell)) upon receiving the first MAC CE (or during LTM execution), upon receiving an RRC reconfiguration including an LTM candidate configuration, or upon / after applying the target LTM candidate configuration. In another embodiment, the UE can deactivate or deconfigure a SCell belonging to the PTAG (i.e., a SCell with the same TA value as the SpCell (serving cell)) based on the target LTM candidate configuration used for the LTM execution process (or via a second (or third) MACCE). In other words, the network can determine the SCell's state via RRC messages or MAC CEs. In yet another embodiment, the UE can activate, deactivate, deconfigure, or configure a SCell based on the target LTM candidate configuration used for the LTM execution process upon receiving the first MAC CE, upon successful completion of LTM execution (or LTM cell handover), or during / after applying the target LTM candidate configuration. In other words, the network can determine the SCell's state via RRC messages.

[0373] For option 2, the network can construct MAC PDUs for the downlink as follows: A MAC PDU consists of one or more MAC sub-PDUs. Each MAC sub-PDU consists of one of the following: - MAC subheader only (including padding); -MAC subheader and MAC SDU; - MAC subheader and MAC CE; -MAC subheader and padding.

[0374] MAC SDUs have variable sizes.

[0375] Each MAC subheader corresponds to MAC SDU, MAC CE, or padding.

[0376] MAC subheaders, except for fixed-size MAC CEs, padded MAC SDUs, and MAC SDUs containing UL CCCHs, consist of the header fields R / F / LCID / (eLCID) / L. MAC subheaders for fixed-size MAC CEs, padded MAC SDUs, and MAC SDUs containing UL CCCHs consist of two header fields: R / LCID / (eLCID).

[0377] Figure 17 An example of a DL MAC PDU according to an embodiment of this disclosure is shown.

[0378] Place the MAC CE together. For example... Figure 17 As shown, the DL MAC sub-PDU with MAC CE is placed before any MAC sub-PDU with MAC SDU and the MAC sub-PDU with padding.

[0379] Upon receiving a second MAC CE (or a third MAC CE) and a first MAC CE, the UE should first process (or read) the second MAC CE (or the third MAC CE) to prepare the SCell for LTM cell handover by activating / deactivating the SCell. Then, the UE can process (or read) the first MAC CE to trigger the LTM cell handover. To simplify UE processing, the order of MAC CEs is defined as the second MAC CE (or the third MAC CE) preceding the first MAC CE.

[0380] In another embodiment, upon receiving a first MAC CE and a second MAC CE (or a third MAC CE), the UE should first process (or read) the first MAC CE to trigger an LTM cell handover. Then, the UE can process (or read) the second MAC CE (or the third MAC CE) to activate / deactivate the SCell (e.g., after a successful LTM cell handover according to the conditions described above). To simplify UE processing, the order of MAC CEs is defined as the first MAC CE being placed before the second MAC CE (or the third MAC CE). The second MAC CE (or the third MAC CE) can be processed upon / after a successful LTM cell handover (when the conditions described above are met).

[0381] Figure 18 An example of a UL MAC PDU according to an embodiment of this disclosure is shown.

[0382] like Figure 18 As shown, in a MAC PDU, the UL MAC sub-PDU with a MAC CE is placed after all the MAC sub-PDUs with a MAC SDU and before the MAC sub-PDU with padding. The padding size can be zero.

[0383] Each MAC entity can send a maximum of one MAC PDU per TB.

[0384] For option 1 or option 2, LTM supports mobility within and between gNB-DUs, as well as within and between gNB-DUs. LTM also supports inter-frequency mobility, including mobility to inter-frequency cells that are not the current serving cell. The following scenarios are supported: - PCell changes in non-CA scenarios In a CA scenario, PCell changes while SCell remains unchanged. - Changes to PCell and SCell in CA scenarios include the following: a) The target PCell / target SCell is not the current serving cell (CA-to-CA scenario with PCell change). b) The target PCell is the current SCell c) The target SCell is the current PCell.

[0385] The fourth MAC CE is the LTM candidate cell TCI state activation / deactivation MAC CE.

[0386] The candidate cell TCI status activation / deactivation MAC CE is identified by a MAC subheader with the eLCID specified in Table 6.2.1-1b. It has a variable size consisting of one or more of the following fields: -LTM Candidate Configuration ID or Candidate Cell ID: This field indicates the identifier of the LTM candidate cell or LTM candidate configuration to which the MAC CE applies, corresponding to the LTM candidate configuration in the RRC reconfiguration. In another embodiment, this field may be replaced by (or omitted from) the target configuration ID in the first MAC CE. For example, when the first MAC CE is received and the target configuration ID is received, the field in the fourth MAC CE may be applied or processed.

[0387] -PI: This field indicates whether each TCI code point has multiple TCI states or a single TCI state. If the Pi field is set to 1, the i-th TCI code point includes both DL TCI and UL TCI states. If the Pi field is set to 0, the i-th TCI code point includes only DL / joint TCI states or UL TCI states. The code point to which a TCI state is mapped is determined by its sequential position in all TCI state ID fields; -D / U: This field indicates whether the TCI status ID in the same octet is used for the combined / downlink or uplink TCI status. If this field is set to 1, the TCI status ID in the same octet is used for the combined / downlink. If this field is set to 0, the TCI status ID in the same octet is used for the uplink. -TCI State ID: This field indicates the TCI state identified by the TCI-StateId or TCI-UL-StateId in the target LTM candidate configuration. If D / U is set to 1, a 7-bit TCI State ID is used (i.e., the TCI-StateId configured in the target LTM candidate configuration). If D / U is set to 0, the most significant bit of the TCI State ID is considered reserved, and the remaining 6 bits indicate the TCI-UL-StateId configured in the target LTM candidate configuration.

[0388] -DL BWP ID: This field indicates the DL BWP used by the UE for the target LTM cell. If this field is present (or included), the MAC entity (or UE) activates the DL BWP indicated by this field for LTM execution or LTM cell handover. If this field is missing (absent or not included), the MAC entity (or UE) activates the DL BWP indicated by the RRC configuration (i.e., the firstActiveDownlinkBWP-Id in the target LTM candidate configuration indicated by the target configuration ID) for LTM execution or LTM cell handover. In another embodiment, a common BWP ID (or the same BWP ID) can indicate both the DL BWP ID and the UL BWPID.

[0389] -UL BWP ID: This field indicates the UL BWP used by the UE for the target LTM cell. If this field is present (or included), the MAC entity (or UE) activates the DL BWP indicated by this field for LTM execution or LTM cell handover. If this field is missing (absent or not included), the MAC entity (or UE) activates the DL BWP indicated by the RRC configuration (i.e., the firstActiveUplinkBWP-Id in the target LTM candidate configuration indicated by the target configuration ID) for LTM execution or LTM cell handover. In another embodiment, a common BWP ID (or the same BWP ID) can indicate both the DL BWP ID and the UL BWP ID.

[0390] -R: Reserved bit, set to 0.

[0391] The fields in the fourth MAC CE refer to the (target LTM candidate configuration) RRC configuration indicated by the target configuration ID field in the first MAC CE. That is, these fields are considered (or processed) after the UE has applied the complete (or referenced) LTM candidate configuration indicated by the target configuration ID in the first MAC CE. It does not refer to the RRC configuration used before / at the time of receiving this MAC CE.

[0392] When MAC CEs are included in the same MAC PDU, the fourth MAC CE can be placed before the first MAC CE, enabling early TCI state processing. In another embodiment, when MAC CEs are included in the same MAC PDU, the fourth MAC CE can be placed after the first MAC CE, enabling rapid application of the indicated LTM candidate cell configuration.

[0393] Random access procedure

[0394] When initiating a random access procedure, the UE selects a set of random access resources and initializes the following parameters used for the random access procedure according to the values ​​configured for the selected set of random access resources in the RRC: -preambleReceivedTargetPower: Initial random access preamble power for 4-step RA type; -powerRampingStep: Power ramping factor; -msgA-PreamblePowerRampingStep: Power ramp-up factor used for MSGA preamble; -ra-PreambleIndex: Random access preamble; -ra-PreambleStartIndex: The starting index for the random access preamble used in on-demand SI requests; -startPreambleForThisPartition: The first preamble associated with this set of random access resources applicable to the random access procedure; -preambleTransMax: The maximum number of random access preamble transmissions. This variable may be disregarded in the random access procedure for TA acquisition of the LTM candidate cell (i.e., the random access procedure for the LTM candidate cell initiated by the PDCCH command). In another embodiment, this variable may be set to a minimum value, such as 1, to avoid discretionary preamble retransmissions. For example, when the random access procedure for TA acquisition of the LTM candidate cell is indicated, triggered, or initiated (e.g., if the random access procedure is initiated by the PDCCH command for the LTM candidate cell), the variable (i.e., preambleTransMax) may be set to 1. In another embodiment, the variable may be considered (or set) to infinity (or zero) in the random access procedure for TA acquisition of the LTM candidate cell to invalidate the variable. For example, when the random access procedure for TA acquisition of the LTM candidate cell is indicated, triggered, or initiated (e.g., if the random access procedure is initiated by the PDCCH command for the LTM candidate cell), the variable (i.e., preambleTransMax) may be set to infinity or zero.

[0395] The following UE variables are used in the random access procedure: -PREAMBLE_INDEX; -PREAMBLE_TRANSMISSION_COUNTER; -PREAMBLE_TRANSMISSION_COUNTER_LTM; -PREAMBLE_POWER_RAMPING_COUNTER; -PREAMBLE_POWER_RAMPING_COUNTER_LTM; -PREAMBLE_POWER_RAMPING_STEP; -PREAMBLE_RECEIVED_TARGET_POWER; -POWER_OFFSET_2STEP_RA; -MSGA_PREAMBLE_POWER_RAMPING_STEP. The contents of the PDCCH command are as follows:

[0396] In this embodiment, when the UE performs an LTM procedure (e.g., LTM execution) via a first MAC CE (i.e., LTM-triggered MAC CE as described above), a RACH-free solution (i.e., LTM cell handover without a random access procedure) is supported. In a RACH-free process, the UE requires a valid TA to send a first UL message during the LTM execution process (i.e., LTM cell handover). To provide a TA by utilizing an earlier RACH procedure (i.e., a random access procedure for PDCCH commands prior to the first MAC CE), this application proposes a random access procedure for PDCCH commands without a RAR (Random Access Response).

[0397] When the random access procedure for TA acquisition in an LTM candidate cell is triggered / indicated by a PDCCH command (e.g., by an indication), the UE performs the random access procedure. Specifically, the UE sends a preamble to the PRACH (Physical Random Access Channel) resource of the indicated LTM candidate cell and completes the random access procedure. In other words, the preamble transmission during this random access procedure for TA acquisition (i.e., the early RACH) can be considered a successful completion of the random access procedure. The preamble or PRACH resource can be indicated by a PDCCH command or (pre-)configured by an RRC message (e.g., an RRCReconfiguration message). To reduce processing complexity, the UE does not calculate the RA-RNTI (RNTI (Radio Network Temporary Identifier)) of the random access response before / at the time of sending the preamble, unlike the normal random access procedure (RACH).

[0398] In addition, to count the number of preamble transmissions used for TA acquisition in LTM candidate cells and perform a power ramp-up process based on this number, the UE needs to maintain a variable called PREAMBLE_POWER_RAMPING_COUNTER. Through this power ramp-up process, the more preambles the UE transmits, the higher the UE's transmit power. However, this principle should apply only when the UE transmits a preamble in the same cell and on the same SSB as the previous preamble; that is, the UE should only increment the variable by 1 when performing a preamble transmission for the same previous preamble transmission (i.e., the same LTM candidate cell and the same SSB (Synchronization Signal Block), for example, considering the frequency and time domain resources of the beam).

[0399] Specifically, the UE should first check the target cell (e.g., whether it is for the serving cell or an LTM candidate cell), the type of preamble transmission (whether it is an initial transmission or a retransmission), and the selected SSB (whether it is the same SSB as the previous preamble transmission or a different SSB). After this identification process, the UE determines how to manage the variables. For example, if the random access procedure is initiated by a PDCCH command for an LTM candidate cell and the PDCCH command indicates an initial preamble transmission, or if the random access procedure is initiated by a PDCCH command for an LTM candidate cell and the LTM candidate cell is different from the previous random access preamble transmission and the PDCCH command indicates a preamble retransmission, then the UE sets (or initializes) PREAMBLE_POWER_RAMPING_COUNTER to 1. However, if the random access procedure is initiated by a PDCCH command for a preamble retransmission of an LTM candidate cell, and if the PDCCH command indicates the same LTM candidate cell and the same SSB as the previous random access preamble transmission, the UE increments PREAMBLE_POWER_RAMPING_COUNTER by 1. After determining the value of the variable, the UE sets the preamble transmission power (i.e., PREAMBLE_RECEIVED_TARGET_POWER) to the calculated value (i.e., preambleReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP + POWER_OFFSET_2STEP_RA) based on the value of PREAMBLE_POWER_RAMPING_COUNTER – 1.

[0400] After / when the random access preamble is sent, if the random access procedure is initiated by a PDCCH command for an LTM candidate cell, the UE considers the random access procedure complete. In the prior art, the UE typically discards the resources configured for random access preamble transmission. However, random access resources used for early uplink synchronization (early TA acquisition procedure) can be reused for preamble retransmissions indicated by a PDCCH command. Therefore, the UE should retain these random access resources instead of discarding them. In other words, upon completion of the random access procedure, the UE discards the resources configured for random access preamble transmission, except for those used for random access procedures (preamble (re)transmission) for LTM candidates triggered by a PDCCH command. Specifically, upon completion of the random access procedure, the UE (or MAC entity) should discard any explicitly signaled contention-free random access resources for 2-step RA types and 4-step RA types, except for contention-free random access resources (if any) used for 4-step RA types and random access procedures for LTM candidate cells triggered by a PDCCH command. When the MAC is reset, the UE discards contention-free random access resources (if any) for the 4-step RA (Random Access) type (or 2-step RA type) for LTM candidate cells, as explicitly signaled. Specifically, if the upper layer requests a MAC entity reset (i.e., the UE performs a MAC reset), or if the MAC entity receives an LTM cell handover command MAC CE on the serving cell (i.e., the UE performs a MAC reset), the UE discards contention-free random access resources (if any) for the 4-step RA (Random Access) type (or 2-step RA type) for LTM candidate cells, as explicitly signaled.

[0401] To achieve this functionality, one of the following options can be implemented: Option 1: In this option, the network can avoid another random access procedure during the random access procedure for TA acquisition (i.e., before the successful completion of TA acquisition). The first preamble transmission for TA acquisition may fail, and the network can request a retransmission of the preamble used for TA acquisition. In this case, the UE increments a first variable (PREAMBLE_POWER_RAMPING_COUNTER), calculates the preamble receive target power, and retransmits the preamble at a higher power than the first preamble. For example, if the random access procedure is not initiated by a PDCCH command for a preamble retransmission against an LTM candidate cell (or if a normal random access procedure is initiated or if a random access procedure for LTM execution (i.e., LTM cell handover) is initiated), the UE sets the first variable to 1. In other words, if the random access procedure is initiated by a PDCCH command for a preamble transmission against an LTM candidate cell (i.e., the first transmission) (or if a normal random access procedure is initiated or if a random access procedure for LTM execution (i.e., LTM cell handover) is initiated), the UE sets the first variable to 1. If the random access procedure is initiated by a PDCCH command for a preamble retransmission against an LTM candidate cell, the UE does not set the first variable to 1. If the random access procedure is initiated by a PDCCH command for a preamble retransmission against an LTM candidate cell, the UE increments the first variable by 1. Based on this, the UE can calculate the preamble reception target power and retransmit the preamble at a higher power than the first preamble. To achieve this, the following procedure can be implemented (the same principle can be applied to other variables (e.g., PREAMBLE_TRANSMISSION_COUNTER): (1) Initialization of the random access procedure When initiating a random access procedure on the serving cell or to an LTM candidate cell (or if the random access procedure is initiated for LTM execution (i.e., LTM cell handover), or if the random access procedure is initiated for TA acquisition of an LTM candidate cell), the MAC entity shall: 1> Refresh the Msg3 buffer; 1> Refresh the MSGA buffer; 1> Set PREAMBLE_TRANSMISSION_COUNTER to 1; 1> If the random access procedure is initiated on the serving cell; or 1> If the random access procedure is initiated by a PDCCH command for an LTM candidate cell, and the PDCCH command indicates the initial transmission of the preamble; or 1> If the random access procedure is initiated by a PDCCH command for an LTM candidate cell, and this LTM candidate cell is different from the previous random access preamble transmission, and the PDCCH command instructs for preamble retransmission: 2> Set PREAMBLE_POWER_RAMPING_COUNTER to 1; 1> If the random access procedure is initiated by a PDCCH command retransmitting a preamble for an LTM candidate cell; and 1> If the PDCCH command indicates the same LTM candidate cell and the same SSB as the previous random access preamble transmission: 2>Increment PREAMBLE_POWER_RAMPING_COUNTER by 1.

[0402] 1>Set PREAMBLE_RECEIVED_TARGET_POWER to preambleReceivedTargetPower +DELTA_PREAMBLE + (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP + POWER_OFFSET_2STEP_RA.

[0403] (2) Random access preamble transmission

[0404] For each random access preamble, the MAC entity should: 1> If PREAMBLE_TRANSMISSION_COUNTER is greater than 1; and 1> No notification to pause the power ramp-up counter was received from the lower layer; and 1> If no LBT failure indication was received from the lower layer for the previous random access preamble transmission; and 1> If the selected SSB or CSI-RS has not changed compared to the selection in the previous random access preamble transmission: 2>Increment PREAMBLE_POWER_RAMPING_COUNTER by 1.

[0405] 1> If the random access procedure is initiated by a PDCCH command as a preamble retransmission for an LTM candidate cell (i.e., for TA acquisition of the cell): 2>Increment PREAMBLE_POWER_RAMPING_COUNTER by 1.

[0406] 1> Select the value of DELTA_PREAMBLE; 1>Set PREAMBLE_RECEIVED_TARGET_POWER to preambleReceivedTargetPower +DELTA_PREAMBLE + (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP + POWER_OFFSET_2STEP_RA; 1> Except for the contention-free random access preamble used for beam failure recovery requests and the random access preamble for LTM candidate cells via PDCCH commands (i.e., for TA acquisition of LTM candidate cells), the UE calculates the RA-RNTI related to the PRACH timing of sending the random access preamble. If the random access preamble is sent via PDCCH commands for TA acquisition of LTM candidate cells, the UE does not need to calculate the RA-RNTI related to the PRACH timing of sending the random access preamble because receiving RAR is not expected. However, for normal random access procedures or random access procedures used for LTM execution (i.e., LTM cell handover), the UE calculates the RA-RNTI related to the PRACH timing of sending the random access preamble.

[0407] 1> Instruct the physical layer to send the random access preamble using the selected PRACH timing, the corresponding RA-RNTI (if available), PREAMBLE_INDEX, and PREAMBLE_RECEIVED_TARGET_POWER.

[0408] 1> If the random access procedure is triggered by a PDCCH command for an LTM candidate cell (i.e., for TA acquisition of the cell): (During the random access procedure (i.e., early RACH) for TA acquisition, the preamble transmission can be considered as the successful completion of the random access procedure).

[0409] 2> Consider the random access procedure to have been successfully completed (or consider the random access response to have been successfully received).

[0410] Option 2: In this option, the network can allow another random access procedure during the random access procedure for TA acquisition (i.e., before the successful completion of TA acquisition) by introducing a second variable (PREAMBLE_POWER_RAMPING_COUNTER_LTM). Furthermore, by having a second variable for each LTM candidate cell, the network can also be extended to support TA acquisition for multiple LTM candidates. The first preamble transmission for TA acquisition may fail, and the network can request a retransmission of the preamble used for TA acquisition. In this case, the UE increments the second variable, calculates the preamble receive target power, and retransmits the preamble at a higher power than the first preamble. For example, if the random access procedure is not initiated by a PDCCH command for a preamble retransmission against an LTM candidate cell, the UE sets the second variable to 1. In other words, if the random access procedure is initiated by a PDCCH command for a preamble transmission against an LTM candidate cell, the UE sets the second variable to 1. If the random access procedure is initiated by a PDCCH command for a preamble retransmission against an LTM candidate cell, the UE does not set the first variable to 1. If the random access procedure is initiated by a PDCCH command retransmitting a preamble for an LTM candidate cell, the UE increments the second variable by 1. Based on this, the UE can calculate the target power for preamble reception and retransmit the preamble at a higher power than the first preamble. However, if a normal random access procedure is initiated, or if a random access procedure for LTM execution (i.e., LTM cell handover) is initiated, the UE sets the first variable to 1. In other words, if a normal random access procedure is initiated, or if a random access procedure for LTM execution (i.e., LTM cell handover) is initiated, the UE sets the first variable to 1. If the random access procedure is initiated by a PDCCH command retransmitting a preamble for an LTM candidate cell, the UE does not set the first variable to 1. If PREAMBLE_TRANSMISSION_COUNTER is greater than 1; and no notification of a pause power ramp counter is received from the lower layer; and no LBT failure indication is received from the lower layer for the previous random access preamble transmission; and if the selected SSB or CSI-RS has not changed relative to the selection in the previous random access preamble transmission, the UE increments the first variable by 1. Based on this, the UE can calculate the target power for receiving the preamble and retransmit the preamble with a higher power than the first preamble. To achieve this, the following procedure can be implemented (the same principle can be applied to other variables (e.g., PREAMBLE_TRANSMISSION_COUNTER): (1) Initialization of the random access procedure When a random access procedure is initiated on the serving cell (or when the random access procedure is initiated for LTM execution (i.e., LTM cell handover)) (and if no random access procedure is initiated on the serving cell for an LTM candidate cell (by including an indicated PDCCH command for TA acquisition of the LTM candidate cell), the MAC entity shall: 1> Refresh the Msg3 buffer; 1> Refresh the MSGA buffer; 1> Set PREAMBLE_TRANSMISSION_COUNTER to 1; 1> Set PREAMBLE_POWER_RAMPING_COUNTER to 1; 1> Set PREAMBLE_BACKOFF to 0 ms; When a random access procedure is initiated on the serving cell to an LTM candidate cell (via a PDCCH command including indications (e.g., LTM candidate cell identifier, TA acquisition, preamble, PRACH resources, etc.) for TA acquisition of the LTM candidate cell), the MAC entity should: 1> Refresh the Msg3 buffer; 1> Refresh the MSGA buffer; 1> Set PREAMBLE_TRANSMISSION_COUNTER_LTM to 1; 1> If the random access procedure is initiated on the serving cell; or 1> If the random access procedure is initiated by a PDCCH command for an LTM candidate cell, and the PDCCH command indicates the initial transmission of the preamble; or 1> If the random access procedure is initiated by a PDCCH command for an LTM candidate cell, and this LTM candidate cell is different from the previous random access preamble transmission, and the PDCCH command instructs for preamble retransmission: 2> Set PREAMBLE_POWER_RAMPING_COUNTER to 1; 1> If the random access procedure is initiated by a PDCCH command retransmitting a preamble for an LTM candidate cell; and 1> If the PDCCH command indicates the same LTM candidate cell and the same SSB as the previous random access preamble transmission: 2>Increment PREAMBLE_POWER_RAMPING_COUNTER by 1.

[0411] 1>Set PREAMBLE_RECEIVED_TARGET_POWER to preambleReceivedTargetPower +DELTA_PREAMBLE + (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP + POWER_OFFSET_2STEP_RA.

[0412] (2) Random access preamble transmission

[0413] For each random access preamble, the MAC entity should: 1> If PREAMBLE_TRANSMISSION_COUNTER is greater than 1; and 1> No notification to pause the power ramp-up counter was received from the lower layer; and 1> If no LBT failure indication was received from the lower layer for the previous random access preamble transmission; and 1> If the selected SSB or CSI-RS has not changed compared to the selection in the previous random access preamble transmission: 2>Increment PREAMBLE_POWER_RAMPING_COUNTER by 1.

[0414] 1> If the random access procedure is initiated by a PDCCH command as a preamble retransmission for an LTM candidate cell (i.e., for TA acquisition of the cell): 2> Increment PREMBLE_POWER_RAMPING_COUNTER_LTM by 1 (or increment PREMBLE_POWER_RAMPING_COUNTER_LTM for LTM candidate cells by 1).

[0415] 1> Select the value of DELTA_PREAMBLE; 1> If the random access procedure is initiated by a PDCCH command for an LTM candidate cell (i.e., for TA acquisition of that cell), set PREAMBLE_RECEIVED_TARGET_POWER to preambleReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_POWER_RAMPING_COUNTER_LTM – 1) × PREAMBLE_POWER_RAMPING_STEP + POWER_OFFSET_2STEP_RA; 1> If the random access procedure is not initiated by a PDCCH command for an LTM candidate cell (i.e., for TA acquisition of that cell), set PREAMBLE_RECEIVED_TARGET_POWER to preambleReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_POWER_RAMPING_COUNTER – 1) × PREAMBLE_POWER_RAMPING_STEP + POWER_OFFSET_2STEP_RA; 1> Except for the contention-free random access preamble used for beam failure recovery requests and the random access preamble for LTM candidate cells via PDCCH commands (i.e., for TA acquisition of LTM candidate cells), the UE calculates the RA-RNTI related to the PRACH timing of sending the random access preamble. If the random access preamble is sent via PDCCH commands for TA acquisition of LTM candidate cells, the UE does not need to calculate the RA-RNTI related to the PRACH timing of sending the random access preamble because receiving RAR is not expected. However, for normal random access procedures or random access procedures used for LTM execution (i.e., LTM cell handover), the UE calculates the RA-RNTI related to the PRACH timing of sending the random access preamble.

[0416] 1> Instruct the physical layer to send the random access preamble using the selected PRACH timing, the corresponding RA-RNTI (if available), PREAMBLE_INDEX, and PREAMBLE_RECEIVED_TARGET_POWER.

[0417] 1> If the random access procedure is triggered by a PDCCH command for an LTM candidate cell (i.e., for TA acquisition of the cell): (During the random access procedure (i.e., early RACH) for TA acquisition, the preamble transmission can be considered as the successful completion of the random access procedure).

[0418] 2> Consider the random access procedure to have been successfully completed (or consider the random access response to have been successfully received).

[0419] Option 3: In this option, multiple bits are introduced into the PDCCH command to explicitly indicate to the UE the number of preamble (re)transmissions. Specifically, when the UE receives a PDCCH command indicating the random access procedure for TA acquisition of the LTM candidate cell, multiple bits explicitly indicate a value (e.g., the number of preamble (retransmissions)). This allows the UE to determine the COUNT value of variables used in the random access procedure (e.g., PREAMBLE_POWER_RAMPING_COUNTER or PREAMBLE_TRANSMISSION_COUNTER) from these multiple bits. For example, if the PDCCH has 2 bits used in this manner, 00 can indicate the first preamble retransmission (i.e., COUNT value = 2), 10 can indicate the third preamble transmission (i.e., COUNT value = 4), and 11 can indicate the fourth preamble transmission (i.e., COUNT value = 5). If the PDCCH does not include these 2 bits, it can indicate the first preamble transmission (i.e., no retransmission). It can be extended to cases with more bits. Such a COUNT value can be determined and set as a variable value for the random access procedure (e.g., PREAMBLE_POWER_RAMPING_COUNTER or PREAMBLE_TRANSMISSION_COUNTER).

[0420] The contents of the PDCCH command that triggers / indicates the random access procedure (i.e., PRACH transmission on the LTM candidate cell) for TA acquisition in the LTM candidate cell can be described in detail, for example, how bits in the PDCCH DCI format are used to indicate the LTM candidate cell. The PDCCH command from the source cell contains an indication of the candidate cell. Reserved bits in the DCI (Downlink Control Information) format 1_0 for the PDCCH command can be used to indicate the cell identifier. Specifically, for a PRACH transmission by a UE triggered by a PDCCH command, if the value of the random access preamble index field is not zero, the PRACH index field indicates the PRACH timing for the PRACH transmission, where the PRACH timing is associated with the SS / PBCH block index indicated by the SS / PBCH block index field of the PDCCH command, and the cell indicator field (if present) indicates the cell for the PRACH transmission. The PDCCH DCI format also includes a 1-bit field in the PDCCH command that explicitly indicates the initial transmission or retransmission of the PRACH.

[0421] For the cell indicator, several options are possible, and one of the options is followed to trigger a random access procedure on an LTM candidate cell via a PDCCH command that indicates one of the LTM candidate cells configured for the UE.

[0422] - Option 1: In this option, the bits in the PDCCH (i.e., in the DCI format) indicate the cell identifier or configuration identifier configured for the LTM candidate cell in the RRC configuration. This makes UE implementation very simple.

[0423] - Option 2: In this option, this application proposes a mapping scheme between bits in the PDCCH and cell identifiers (or configuration identifiers) in the RRC configuration (i.e., bitmap) to save bits in the PDCCH.

[0424] For option 2, the following bitmap structure in DCI format is provided.

[0425] - For UEs configured with (full or reference) LTM configuration on PCell or SpCell, the PDCCH DCI format content includes: - Bits indicating preamble transmission or retransmission - The field indicating the random access procedure (i.e., PRACH transmission (or retransmission) on the LTM candidate cell) for TA acquisition is a bitmap of size equal to the number of LTM candidate cells (or configurations) configured in the RRC configuration.

[0426] Each bit in the bitmap corresponds to a configured LTM candidate cell (or configuration) from the stated number of configured LTM candidate cells (or configurations) in ascending (or descending) order of cell identifier (or configuration identifier). This mapping can begin from either the LSB (least significant bit) or the MSB (most significant bit).

[0427] - When multiple configured LTM candidate cells (or configurations) are provided to the UE via RRC configuration, a bitmap is provided, in which...

[0428] - A bitmap position immediately follows a bit position that has already been used for its own purpose.

[0429] - The bitmap size is equal to the number of configured LTM candidate cells (or configurations), wherein each bit of the bitmap corresponds to a configured LTM candidate cell (or configuration) from the number of configured LTM candidate cells (or configurations).

[0430] - A "1" value (or "0" value) in a bitmap indicates a preamble transmission or retransmission on the corresponding LTM candidate cell.

[0431] A "0" (or "1") value for a bit in the bitmap indicates that there was no preamble transmission or retransmission on the corresponding LTM candidate cell. The UE can ignore this bit.

[0432] - When the UE detects a "1" value in a bit of the bitmap, the UE does not need to detect the subsequent bits to reduce the UE's processing burden. This is because the subsequent bits have a "0" value, meaning that only one bit in the bitmap can have a "1" value.

[0433] - For preamble transmission or retransmission, the UE sets the active BWP (e.g., UL BWP) to the active BWP indicated in the PDCCH (e.g., UL BWP) or the active BWP indicated in the RRC configuration (e.g., firstActiveBWP or firstActiveUplinkBWP or defaultBWP or defaultUplinkBWP or initialBWP or initialUplinkBWP).

[0434] The RRC configuration for PRACH transmission parameters can be provided to the UE, for example, via LTM-CFRA-ToAddModList for LTM candidate cells. The UE can trigger PRACH transmission on the serving cell via a PDCCH command received by the UE on the serving cell, which includes an indication of the cell for PRACH transmission. The UE then transmits PRACH on that cell. The TCI-State, for example, uplink or downlink, or both (i.e., combined UL / DL, a unified TCI state for applicable reception or transmission on cells from multiple cells), can be provided to the UE via the MAC CE in the PDSCH reception on the serving cell. If the MAC CE indicates TCI-State and / or TCI-UL-State and / or TCI-DL-State, the UE applies that TCI-State and / or TCI-UL-State and / or TCI-DL-State starting from the first time slot after the last symbol of the PUCCH or PUSCH with HARQ-ACK information for the PDSCH providing the MAC CE.

[0435] In this embodiment, LTM procedures (e.g., LTM execution, random access procedures for TA acquisition in LTM candidate cells (i.e., PRACH transmissions on LTM candidate cells), etc.) are not applied to (or indicated or executed on) the dormant BWP to facilitate UE implementation. The dormant BWP is one of the downlink BWPs configured by the network via dedicated RRC signaling. In a dormant BWP, the UE stops monitoring the PDCCH on / for the SCell, but continues to perform CSI measurements, automatic gain control (AGC), and beam management if configured. For each serving cell other than the SpCell or PUCCH SCell or LTM candidate cell, the network can configure a BWP as a dormant BWP. For example, for an LTM candidate cell, the network does not configure a BWP (e.g., firstActiveDownlinkBWP, initialBWP, or defaultBWP) as a dormant BWP. For example, a dormant BWP is one of the UE's dedicated BWPs configured by the network via dedicated RRC signaling. SPcell, PUCCHSCell, and LTM candidate cells cannot be configured with dormant BWPs.

[0436] During the aforementioned random access procedures used for early TA acquisition (early uplink synchronization) or LTM cell handover, if the UE initiates another random access procedure, variable initialization will be performed, and unexpected values ​​will lead to errors and inappropriate UE behavior. Therefore, if an ongoing LTM cell handover exists, the UE should not trigger another random access procedure. For example, in the case of a scheduling request (SR), the UE (MAC entity) initiates a random access procedure on the SpCell, and the pending scheduling request is canceled only if there is no ongoing LTM cell handover (or early TA acquisition) and if the MAC entity does not have a valid PUCCH resource configured for the pending scheduling request.

[0437] Specifically, as long as at least one SR is pending, for each pending SR, the MAC entity should: 1> If the MAC entity does not have a valid PUCCH resource configured for the pending SR, and 1> There is no ongoing LTM cell handover or no ongoing early uplink synchronization (or early TA acquisition process): 2> Initiate a random access procedure on SpCell and cancel pending SRs.

[0438] Completion of the random access procedure

[0439] It would be beneficial to have cross-layer interaction between the MAC layer and the RRC layer, enabling the RRC layer to perform RRC-specific behaviors (e.g., stopping the supervisory timer used in the LTM execution process). To this end, this application proposes the following behaviors: When completing the random access procedure, the MAC entity should: 1> Except for the 4-step RA type contention-free random access resources (if any) used for beam failure recovery requests and random access procedures for LTM candidate cells triggered by PDCCH commands, discard any contention-free random access resources explicitly signaled for 2-step RA type and 4-step RA type. 1> Refresh the HARQ buffer used for transmitting MAC PDUs in the Msg3 and MSGA buffers.

[0440] Upon successful completion of the random access procedure initiated for DAPS handover, the target MAC entity should: 1> Indicate the successful completion of the random access procedure to the upper layer.

[0441] Upon successful completion of a random access procedure initiated for an LTM execution (or LTM cell handover or LTM execution process or by receiving the first MAC CE), the MAC entity shall: 1> Indicate to the upper layer the successful completion of the random access procedure (or LTM execution procedure).

[0442] Upon successful completion of an LTM execution procedure initiated by receiving the first MAC CE (or LTM cell handover or LTM execution procedure initiated by receiving the first MAC CE), the MAC entity shall: 1> Indicate the successful completion of the LTM execution process to the upper layer.

[0443] For LTM execution procedures based on RACH (i.e., LTM execution procedures with random access procedures), the UE considers the LTM execution procedure to have been successfully completed when RACH is successfully completed.

[0444] For LTM execution without RACH (i.e., LTM execution without random access procedure), the UE considers the LTM execution to be successfully completed when it determines that the network has successfully received its first UL data (e.g., by checking the reception of HARQ ACK or RLCACK for the first UL data, or the reception of the PDCCH addressed by C-RNTI, or when the UE contention resolution identifier MAC CE is received).

[0445] LTM execution process (or LTM commands)

[0446] In this embodiment, as previously described, TA acquisition of candidate cells is supported prior to the LTM cell handover command. In this way, when the source cell / DU learns the value and validity of the candidate cell's TA, it can determine whether it can initiate a RACH-free solution for LTM cell handover, and then determine whether it needs to include beam indication (e.g., TCI status) and TA information in the first MAC CE (i.e., the LTM command MAC CE), as described in Section 4.1. Therefore, the network can indicate a valid TA to the UE or indicate whether the TA is still valid in the first MAC CE. Upon receiving the TA information indicated in the LTM MAC CE, the UE can apply the TA value and start a TA timer for the target LTM candidate cell during LTM execution (i.e., LTM cell handover). If the TAT for the target LTM candidate cell is running (i.e., the TA value is valid) or if no beam fault is detected for the target LTM candidate cell, the UE can perform an LTM cell handover without a random access procedure (i.e., using a RACH-free solution). This means the UE can monitor the PDCCH from the target LTM candidate cell, or the UE can use configuration authorization to send first UL data to the target cell for RACH-free LTM execution (LTM cell handover). Otherwise, the UE can perform the LTM execution procedure using a random access procedure.

[0447] In this embodiment, the first MAC CE to be sent to the UE can be generated by the source cell (or gNB). That is, the MAC entity of the source cell (or gNB) generates the first MAC CE including content (e.g., TA value or BWP ID, configuration identifier, etc. as mentioned above) and sends it to the UE to trigger the LTM cell handover process.

[0448] In another embodiment, the first MAC CE to be sent to the UE can be generated by the target cell (or gNB or CU (centralized unit)). That is, the MAC entity of the target cell (or gNB or CU (centralized unit)) generates a first MAC CE including content (e.g., TA value or BWP ID, configuration identifier, etc. as described in Section 4.1) and forwards it to the source cell (or DU (distributed unit)) (e.g., in an Xn message via the Xn interface, or in an RRC message, or in an F1-AP message). The source cell (or DU) sends it to the UE to trigger the LTM cell handover procedure.

[0449] To efficiently maintain uplink time alignment, one of the proposed options for MAC entity behavior can be implemented: The RRC configuration uses the following parameters to maintain UL time alignment: -timeAlignmentTimer (per TAG) controls the duration for which the MAC entity considers the serving cell belonging to the associated TAG as having uplink time alignment. Option 1: In this option, the timing advance command value (or field) is optional in the first MAC CE (i.e., it can be present or absent). Upon receiving the first MAC CE (LTM command MAC CE), the corresponding MAC behavior is as follows: MAC entities should: 1> If the MAC entity receives the LTM command MAC CE on the serving cell: 2> Indicate to the upper layer that the LTM command MAC CE has been received (triggering the LTM cell handover process); 2> Perform a MAC reset; 2> Indicate the target configuration ID (i.e., the identifier of the target LTM candidate cell) included in the MAC CE to the upper layer. 2> If the timing advance command value exists (or is included), or if the timing advance command indicates that the timing advance value needs to be updated or is no longer valid, or if it indicates that the timing advance should be maintained or the TA of the source cell (or serving cell) should be used (i.e., the LTM candidate cell indicated by the target configuration ID (or serving cell ID) in the first MAC CE belongs to the PTAG), or if the timing advance command value is not set to a specific value (e.g., 000..0 or 111…1) (e.g., this value indicates no RACH LTM candidate cell handover), or if an RRC parameter indicating no RACH LTM execution (or indicating the same value as the serving cell) is configured: 3. Process the received timing advance command. In another embodiment, if the timing advance command indicates that the timing advance value needs to be updated or is no longer valid, or if it does not indicate to maintain the timing advance or use the TA of the source cell (or serving cell), the UE can process the received timing advance command to avoid unnecessary processing; 3> When an LTM command MAC CE including a timing advance command is received (or if the timing advance command indicates that the timing advance value needs to be updated or is no longer valid, or if it does not indicate to maintain the timing advance or use the TA of the source cell (or serving cell): 4> Apply timing advance command to PTAG or target LTM candidate cell (or indicated LTM candidate cell) (i.e., the UE can apply and store timing advance value for PTAG or target LTM candidate cell). 4> Start or restart the timeAlignmentTimer associated with the PTAG or target LTM candidate cell (or the indicated LTM candidate cell); In another embodiment, the UE may start or restart the timeAlignmentTimer associated with the PTAG or target LTM candidate cell (or the indicated LTM candidate cell) only if the timeAlignmentTimer associated with the PTAG or target LTM candidate cell (or the indicated LTM candidate cell) is not running, in order to avoid unnecessary update processes.

[0450] 3> Instruct the upper layer to skip the random access procedure for the LTM cell handover or the target LTM candidate cell (or the indicated LTM candidate cell). In another embodiment, if the TAT (timeAlignmentTimer) of the target / indicated LTM candidate cell (or PTAG) is running (i.e., the TA value is valid), or no beam failure of the target LTM candidate cell is detected (i.e., BFI_COUNTER < beamFailureInstanceMaxCount of the target / indicated LTM candidate cell (the number of beam failure indications is less than the maximum number used for beam failure detection)), the UE may instruct the upper layer to skip the random access procedure for the LTM cell handover or the target LTM candidate cell (or the indicated LTM candidate cell).

[0451] 2> Otherwise (if the timing advance command value is missing (or not included), or if it is not indicated to maintain timing advance or use the TA of the source cell (or serving cell) (i.e., the LTM candidate cell indicated by the target configuration ID (or serving cell ID) in the first MAC CE does not belong to the PTAG), or if the timing advance command value is set to a special value (e.g., 000..0 or 111…1) (e.g., this value indicates RACH-based LTM candidate cell handover), or if the RRC parameter indicating no RACH LTM execution (or indicating the same value as the serving cell) is not configured: 3> Indicate to the upper layer that the LTM cell handover or the target LTM candidate cell (or the indicated LTM candidate cell) requires a random access procedure, or instruct the upper layer to trigger a random access procedure for the LTM cell handover or the target LTM candidate cell (or the indicated LTM candidate cell); In another embodiment, if the TAT (timeAlignmentTimer) of the target / indicated LTM candidate cell (or PTAG) is not running (i.e., the TA value is invalid), or the target / indicated LTM candidate cell detects beam failure (i.e., BFI_COUNTER >= beamFailureInstanceMaxCount of the target / indicated LTM candidate cell (or PTAG) (the number of beam failure indications is greater than or equal to the maximum number used for beam failure detection)), then the UE may indicate to the upper layer that the LTM cell handover or the target LTM candidate cell (or the indicated LTM candidate cell) requires a random access procedure.

[0452] 3> The UE can ignore the received advance timing command to avoid unnecessary update processes.

[0453] 2> If TCI status information is included: 3> The SSB corresponding to the indicated TCI state is regarded as the selected SSB for initial uplink transmission to the candidate cell; 3> Indicate to the lower layer the information about TCI status included in the LTM command MAC CE.

[0454] Option 2: In this option, the advance timing command value (or field) is always present in the first MAC CE (LTM command MAC CE). Upon receiving the first MAC CE (LTM command MAC CE), the corresponding MAC behavior is as follows: MAC entities should: 1> If the MAC entity receives the LTM command MAC CE on the serving cell: 2> Indicate to the upper layer that the LTM command MAC CE has been received (triggering the LTM cell handover process); 2> Perform MAC reset; 2> Indicate the target configuration ID (i.e., the identifier of the target LTM candidate cell) included in the MAC CE to the upper layer; 2> If the timing advance command value is not set to a special value (e.g., 000..0 or 111…1), or if the timing advance command indicates that the timing advance value needs to be updated or is no longer valid, or if an RRC parameter indicating no RACH LTM execution (or indicating the same value as the serving cell) is configured: 3> Process the received timing advance command; 3> When receiving an LTM command MAC CE that includes a timing advance command: 4> Apply timing advance command to PTAG or target LTM candidate cell (or indicated LTM candidate cell) (i.e., the UE can apply and store timing advance value for PTAG or target LTM candidate cell). 4> Start or restart the timeAlignmentTimer associated with the PTAG or target LTM candidate cell (or the indicated LTM candidate cell); In another embodiment, the UE may start or restart the timeAlignmentTimer associated with the PTAG or target LTM candidate cell (or the indicated LTM candidate cell) only if the timeAlignmentTimer associated with the PTAG or target LTM candidate cell (or the indicated LTM candidate cell) is not running, in order to avoid unnecessary update processes.

[0455] 3> Instruct the upper layer to skip the random access procedure for the LTM cell handover or the target LTM candidate cell (or the indicated LTM candidate cell). In another embodiment, if the TAT (timeAlignmentTimer) of the target / indicated LTM candidate cell (or PTAG) is running (i.e., the TA value is valid), or no beam failure of the target LTM candidate cell is detected (i.e., BFI_COUNTER < beamFailureInstanceMaxCount of the target / indicated LTM candidate cell (the number of beam failure indications is less than the maximum number used for beam failure detection)), the UE may instruct the upper layer to skip the random access procedure for the LTM cell handover or the target LTM candidate cell (or the indicated LTM candidate cell).

[0456] 2> Otherwise (if the timing advance command value is set to a special value (e.g., 000..0 or 111…1)), or if the RRC parameter indicating no RACH LTM execution (or indicating the same value as the serving cell) is not configured: 3> Indicate to the upper layer that the LTM cell handover or the target LTM candidate cell (or the indicated LTM candidate cell) requires a random access procedure, or instruct the upper layer to trigger a random access procedure for the LTM cell handover or the target LTM candidate cell (or the indicated LTM candidate cell); In another embodiment, if the TAT (timeAlignmentTimer) of the target / indicated LTM candidate cell (or PTAG) is not running (i.e., the TA value is invalid), or the target / indicated LTM candidate cell detects beam failure (i.e., BFI_COUNTER >= beamFailureInstanceMaxCount of the target / indicated LTM candidate cell (or PTAG) (the number of beam failure indications is greater than or equal to the maximum number used for beam failure detection)), then the UE may indicate to the upper layer that the LTM cell handover or the target LTM candidate cell (or the indicated LTM candidate cell) requires a random access procedure.

[0457] 3> The UE can ignore the received advance timing command to avoid unnecessary update processes.

[0458] 2> If TCI status information is included: 3> The SSB corresponding to the indicated TCI state is regarded as the selected SSB for initial uplink transmission to the candidate cell; 3> Indicate to the lower layer the information about TCI status included in the LTM command MAC CE.

[0459] Alternatively, in this disclosure, the TA value (e.g., timing advance command) can be configured in each LTM candidate cell configuration in the RRCReconfiguration message and can be applied to the maintenance of the UE or TAT timer.

[0460] The network can activate and deactivate the TCI state of an LTM candidate cell configured in the RRC configuration by sending a fourth MAC CE (i.e., the LTM candidate cell TCI state activation / deactivation MAC CE described in Section 4.1). To achieve this, this application proposes several options for activating and deactivating the TCI state during LTM execution, and one of these options can be implemented: - Option 1: In this option, we can restrict the transmission of the fourth MAC CE to be transmitted together with the first MAC CE (the LTM command MAC CE described in Section 4.1). For example, the network can send the fourth MAC CE together with the first MAC CE (i.e., both MAC CEs can be included in the same MAC PDU) to activate and deactivate the TCI state for LTM cell handover. If the MAC entity receives a candidate cell TCI state activation / deactivation MAC CE on the serving cell, it indicates to the lower layer (i.e., the PHY layer (physical layer)) information about the candidate cell TCI state activation / deactivation MAC CE from the indicated LTM candidate cell of the first MAC CE. If the fourth MAC CE is not received (e.g., together with the first MAC CE), the MAC entity indicates to the lower layer to use the TCI indicated (or configured) by RRCReconfiguration for the indicated LTM candidate cell from the first MAC CE, or the lower layer uses the TCI indicated (or configured) by RRCReconfiguration for the indicated LTM candidate cell from the first MAC CE.

[0461] Option 2: In this option, the application does not restrict the transmission of the fourth MAC CE. That is, the network may send the fourth MAC CE before or without considering the transmission of the first MAC CE (the LTM command MAC CE described in Section 4.1) to activate and deactivate the TCI state for LTM cell handover. However, even if the MAC entity receives the candidate cell TCI state activation / deactivation MAC CE on the serving cell, it will still indicate to the lower layer (i.e., the PHY layer) information about the candidate cell TCI state activation / deactivation MAC CE of the indicated LTM candidate cell upon receiving the first MAC CE or during LTM execution. If a fourth MAC CE is not received, the MAC entity instructs the lower layer to use the TCI indicated (or configured) by RRCReconfiguration for the indicated LTM candidate cell from the first MAC CE when the first MAC CE is received or when LTM is performed, or the lower layer uses the TCI indicated (or configured) by RRCReconfiguration for the indicated LTM candidate cell from the first MAC CE.

[0462] SCG activation / deactivation

[0463] RRC configures the following parameters in beamFailureRecoveryConfig, beamFailureRecoverySpCellConfig, beamFailureRecoverySCellConfig, and radioLinkMonitoringConfig, which are used for beam failure detection and recovery: - beamFailureInstanceMaxCount for beam failure detection (for each serving cell or for each BFD-RS set of a serving cell configured with two BFD-RS sets). - beamFailureDetectionTimer for beam failure detection (for each serving cell or for each BFD-RS set of a serving cell configured with two BFD-RS sets). - beamFailureRecoveryTimer for SpCell beam failure recovery process.

[0464] The following UE variables are used in the beam failure detection process: -BFI_COUNTER (for each serving cell or for each BFD-RS set of a serving cell configured with two BFD-RS sets): A counter used to indicate beam failure instances, which is initially set to 0.

[0465] The network can activate and deactivate the configured SCG.

[0466] For the configured SCG, the MAC entity should: 1> If the upper-level instruction SCG is activated: 2> If BFI_COUNTER >= PSCell's beamFailureInstanceMaxCount or the timeAlignmentTimer associated with PTAG is not running: 3> Instruct the upper layer that SCG activation requires a random access procedure.

[0467] 2> Activate SCG according to a set time.

[0468] 2> Re-initialize any suspended configuration uplink authorizations of configuration authorization type 1 associated with the PSCell according to the storage configuration (if any), and start in the symbol according to the rules; 2> Apply normal SCG operations, including: 3> SRS transmission on PSCell; 3> CSI report for PSCell; 3> Perform PDCCH monitoring on PSCell; 3> Perform PUCCH transmission on PSCell; 3> Transmit on RACH on PSCell; 3> Initialize Bj of each logical channel to 0.

[0469] 1> Otherwise, if the upper layer instructs SCG to be deactivated: 2> Deactivate all SCells of SCG; 2> Activate SCG according to a set timer; 2> Clear downlink allocations and uplink license type 2 for any configuration associated with PSCell; 2> Suspend uplink license type 1 for any configuration associated with PSCell; 2> Reset the MAC address according to section 4.7.

[0470] 1> If SCG is deactivated: 2> Do not send SRS on PSCell; 2> Do not report CSI for PSCell; 2> Do not send data on the UL-SCH of the PSCell; 2> Do not send PUCCH on PSCell; 2> Do not send on RACH on PSCell; 2> Do not monitor PDCCH on PSCell.

[0471] When a UE is configured with dual connectivity, the network can activate and deactivate the configured SCG.

[0472] Synchronous reconfiguration

[0473] The UE will perform the following actions to perform a synchronized reconfiguration.

[0474] 1> If AS security is not activated, then as specified in 5.3.11, the action is performed when entering RRC idle, and the release reason is "other", at which point the process ends; 1> If timer T430 is running, stop the timer; 1> Based on the NTN configuration of the target cell, starting from the subframe indicated by epochTime, start timer T430 and set the timer value to ntn-UlSyncValidityDuration; 1> If DAPS bearer is not configured: 2> If the timer T310 for the corresponding SpCell is running, stop the timer; 1> If this procedure is performed against MCG: 2> If timer T316 is running; 3> Stop timer T316; 3> Remove any information included in the VarRLF-Report; 2> If MCG transmission is paused, MCG transmission will resume.

[0475] 1> If timer T312 for the corresponding SpCell is running, stop the timer; 1> If sl-PathSwitchConfig is included: 2> Treat the target L2 U2N relay UE as the UE indicated by targetRelayUE-Identity in sl-PathSwitchConfig; 2> For the corresponding L2 U2N trunk UE, start timer T420 and set the timer value to T420 included in sl-PathSwitchConfig; 2> Apply the value of newUE-Identity as C-RNTI; 2> Indicate the target L2 U2N relay UE indicated by targetRelayUE-Identity to the upper layer (to trigger PC5 unicast link establishment); 2> For SRB1, apply the default configuration of SL-RLC1 as defined in 9.2.4; 1> Otherwise (excluding sl-PathSwitchConfig): 2> If the procedure is performed on an MCG, or if the procedure is performed on an SCG that is not indicated to be deactivated in an E-UTRA or NR RRC message (with an embedded RRCReconfiguration message): 3> For the corresponding SpCell, start timer T304 and set the timer value to t304 included in reconfigurationWithSync; 2> If frequencyInfoDL is included: 3> Treat the target SpCell as an SpCell on the SSB frequency indicated by frequencyInfoDL, with a physical cell identifier indicated by physCellId; 2> Otherwise: 3> Consider the target SpCell as an SpCell on the SSB frequency of the source SpCell, with a physical cell identifier indicated by physCellId; 2> Begin DL synchronization with the target SpCell; 2> Apply the BCCH configuration defined in 9.1.1.1 to the target SPcell; 2> Obtain the MIB of the target SpCell, which is scheduled according to the provisions in TS 38.213

[13] ; T304 expired (reconfiguration with synchronization failed) or T420 expired (path switching failed). UE should: 1> If MCG's T304 expires; or 1> If T420 expires; or, 1> If the target L2 U2N relay UE (i.e., the UE indicated by targetRelayUE-Identity in the received RRCReconfiguration message, as specified in Section 5.3.5.5.2, the RRCReconfiguration message includes a reconfigurationWithSync indicating a path handover): 2> If configured, release the special preamble provided in rach-ConfigDedicated; 2> If configured, release the dedicated msgA PUSCH resource provided in rach-ConfigDedicated; 2> If any DAPS bearer is configured, and according to Section 5.3.10.3, no wireless link failure is detected in the source PCell: 3> Reset the MAC address of the target PCell and release the MAC configuration of the target PCell; 3> For each DAPS bearer: 4> Release one or more RLC entities and the associated logical channel of the target PCell, as specified in Section 5.1.3 of TS 38.322 [4]; ...

Claims

1. A method performed by a user equipment (UE) in a wireless communication system, the method comprising: Receive physical downlink control channel (PDCCH) commands from the base station for triggering random access procedures on mobility LTM candidate cells in Layer 1 / Layer 2; Based on the PDCCH command, a random access preamble for early timing advance TA acquisition of the LTM candidate cell is sent. as well as Receive a cell handover command from the base station, including the TA value of the LTM candidate cell. Wherein, since the random access procedure is initiated by the PDCCH command, the bandwidth portion BWP operation is not performed on the LTM candidate cell.

2. The method according to claim 1, wherein, The BWP operation includes at least one of the following operations: The transmission of the uplink shared channel UL-SCH on the BWP of the LTM candidate cell. The transmission of the random access preamble on the random access channel RACH on the BWP. Monitoring of the PDCCH on the BWP, The transmission of the Physical Uplink Control Channel (PUCCH) on the BWP The Channel State Information (CSI) report on the BWP, or The reception of the downlink DL-SCH on the BWP.

3. The method according to claim 1, further comprising: The power ramp counter of the random access preamble is set to 1 in the following situations: the PDCCH command indicates the initial transmission of the random access preamble; or the LTM candidate cell is different from the LTM candidate cell of the previous random access preamble transmission, and the PDCCH command indicates the retransmission of the random access preamble; and The power ramp counter is incremented by 1 in the following cases: the random access procedure is initiated by the PDCCH command for the LTM candidate cell as a retransmission of the random access preamble; and the PDCCH command indicates that the LTM candidate and synchronization signal block SSB associated with the random access preamble are the same as the LTM candidate associated with the previous random access preamble and the SSB associated with the previous random access preamble.

4. The method according to claim 1, further comprising: If a valid Physical Uplink Control Channel (PUCCH) resource for scheduling request (SR) and an ongoing LTM cell handover are unavailable, a random access procedure is initiated.

5. A method performed by a base station in a wireless communication system, the method comprising: Send the Physical Downlink Control Channel (PDCCH) command to the User Equipment (UE) for triggering random access procedures on the Mobility LTM candidate cell in Layer 1 / Layer 2; as well as Send a cell handover command to the UE, including the timing advance TA value of the LTM candidate cell. The random access preamble used for early TA acquisition in the LTM candidate cell is based on the PDCCH command, and Wherein, since the random access procedure is initiated by the PDCCH command, the bandwidth portion BWP operation is not performed on the LTM candidate cell.

6. The method according to claim 5, wherein, The BWP operation is associated with at least one of the following operations: The uplink shared channel UL-SCH on the BWP of the LTM candidate cell The random access preamble on the random access channel RACH on the BWP The PDCCH on the BWP, The Physical Uplink Control Channel (PUCCH) on the BWP The Channel State Information (CSI) on the BWP, or The downlink DL-SCH on the BWP.

7. The method according to claim 5, wherein, The power ramp counter for the random access preamble is set to 1 in the following situations: the PDCCH command indicates the initial transmission of the random access preamble; or the LTM candidate cell is different from the LTM candidate cell of the previous random access preamble transmission, and the PDCCH command indicates the retransmission of the random access preamble; and The power ramp counter is incremented by 1 in the following cases: the random access procedure is initiated by the PDCCH command for the LTM candidate cell as a retransmission of the random access preamble; and the PDCCH command indicates that the LTM candidate and synchronization signal block SSB associated with the random access preamble are the same as the LTM candidate associated with the previous random access preamble and the SSB associated with the previous random access preamble.

8. The method according to claim 5, wherein, A random access procedure is initiated when there is no valid physical uplink control channel (PUCCH) resource for scheduling request (SR) and no ongoing LTM cell handover.

9. A user equipment (UE) in a wireless communication system, the UE comprising: transceiver; as well as The controller, connected to the transceiver, is configured to: Receive physical downlink control channel (PDCCH) commands from the base station for triggering random access procedures on mobility LTM candidate cells in Layer 1 / Layer 2; Based on the PDCCH command, a random access preamble for early timing advance TA acquisition of the LTM candidate cell is sent. as well as Receive a cell handover command from the base station, including the TA value of the LTM candidate cell. Wherein, since the random access procedure is initiated by the PDCCH command, the bandwidth portion BWP operation is not performed on the LTM candidate cell.

10. The UE according to claim 9, wherein, The BWP operation includes at least one of the following operations: The transmission of the uplink shared channel UL-SCH on the BWP of the LTM candidate cell. The transmission of the random access preamble on the random access channel RACH on the BWP. Monitoring of the PDCCH on the BWP, The transmission of the Physical Uplink Control Channel (PUCCH) on the BWP The Channel State Information (CSI) report on the BWP, or The reception of the downlink DL-SCH on the BWP.

11. The UE according to claim 9, wherein, The controller is further configured to: The power ramp counter of the random access preamble is set to 1 in the following situations: the PDCCH command indicates the initial transmission of the random access preamble; or the LTM candidate cell is different from the LTM candidate cell of the previous random access preamble transmission, and the PDCCH command indicates the retransmission of the random access preamble; and The power ramp counter is incremented by 1 in the following cases: the random access procedure is initiated by the PDCCH command for the LTM candidate cell as a retransmission of the random access preamble; and the PDCCH command indicates that the LTM candidate and synchronization signal block SSB associated with the random access preamble are the same as the LTM candidate associated with the previous random access preamble and the SSB associated with the previous random access preamble.

12. The UE according to claim 9, wherein, The controller is further configured to: If a valid Physical Uplink Control Channel (PUCCH) resource for scheduling request (SR) and an ongoing LTM cell handover are unavailable, a random access procedure is initiated.

13. A base station in a wireless communication system, the base station comprising: transceiver; as well as The controller, connected to the transceiver, is configured to: Send the Physical Downlink Control Channel (PDCCH) command to the User Equipment (UE) for triggering random access procedures on the Mobility LTM candidate cell in Layer 1 / Layer 2; as well as Send a cell handover command to the UE, including the timing advance TA value of the LTM candidate cell. The random access preamble used for early TA acquisition in the LTM candidate cell is based on the PDCCH command, and Wherein, since the random access procedure is initiated by the PDCCH command, the bandwidth portion BWP operation is not performed on the LTM candidate cell.

14. The base station according to claim 13, wherein, The BWP operation is associated with at least one of the following operations: The uplink shared channel UL-SCH on the BWP of the LTM candidate cell The random access preamble on the random access channel RACH on the BWP The PDCCH on the BWP, The Physical Uplink Control Channel (PUCCH) on the BWP The Channel State Information (CSI) on the BWP, or The downlink DL-SCH on the BWP.

15. The base station according to claim 13, wherein, The power ramp counter for the random access preamble is set to 1 in the following situations: the PDCCH command indicates the initial transmission of the random access preamble; or the LTM candidate cell is different from the LTM candidate cell of the previous random access preamble transmission, and the PDCCH command indicates the retransmission of the random access preamble; and The power ramp counter is incremented by 1 in the following cases: the random access procedure is initiated by the PDCCH command for the LTM candidate cell as a retransmission of the random access preamble; and the PDCCH command indicates that the LTM candidate and synchronization signal block SSB associated with the random access preamble are the same as the LTM candidate associated with the previous random access preamble and the SSB associated with the previous random access preamble.

Images