Improvements in and relating to L1 / L2 triggered mobility (LTM) in telecommunication networks

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 communication system is provided. The method comprises: receiving a radio resource control (RRC) message, the RRC message comprising a configuration of a mobility (LTM) associated with a Layer 1 (L1) / Layer 2 (L2) triggered LTM cell handover procedure; identifying that the LTM cell switching process is triggered; and releasing the current dedicated radio configuration associated with the cell group for which the LTM cell handover procedure is triggered, where the current dedicated radio configuration other than an MCG cell-radio network temporary identifier (C-RNTI) is released in the event that the LTM cell handover procedure is triggered on a primary cell group (MCG).

Description

Technical Field

[0001] This disclosure relates to improvements to Layer 1 (L1) / Layer 2 (L2) triggered mobility (LTM) in telecommunications networks. Background Technology

[0002] Fifth-generation (5G) mobile communication technology defines a wide frequency band, enabling high transmission rates and new services. It can be implemented not only in the "sub-6 GHz" band, such as 3.5 GHz, but also in the "above 6 GHz" band, including 28 GHz and 39 GHz, known as millimeter wave (mmWave). Furthermore, sixth-generation (6G) mobile communication technology (called "super 5G systems") is being considered in terahertz (THz) bands (e.g., the 95 GHz to 3 THz band) to achieve transmission rates fifty 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 Communications (URLLC), and massive Machine-Type Communications (mMTC), standardization has been underway for the following: beamforming and massive MIMO to mitigate radio wave path loss and increase radio wave transmission distance in millimeter waves; support for basic parameter sets (e.g., operating multiple subcarrier spacings) for efficient utilization of millimeter wave resources and dynamic operation of time slot formats; initial access technologies to support multi-beam transmission and broadband; definition and operation of the Bandwidth Part (BWP); new channel coding methods, such as low-density parity-check (LDPC) codes for large-scale data transmission and polar codes for highly reliable transmission of control information; L2 preprocessing; and network slicing to provide dedicated networks for specific services.

[0004] Currently, given the services that 5G mobile communication technology will support, discussions are underway regarding improvements and performance enhancements to the initial 5G mobile communication technology, and physical layer standardization already exists for technologies such as: Vehicle-to-everything (V2X), used to assist autonomous vehicles in determining driving based on information sent by the vehicle about its location and status, and to enhance user convenience; New Radio Unlicensed (NR-U), for system operation in compliance with various regulatory requirements in unlicensed frequency bands; NR UE power saving; Non-Terrestrial Network (NTN), which is UE-satellite direct communication used to provide coverage in areas where communication with terrestrial networks is unavailable; and positioning.

[0005] Furthermore, standardization is underway in air interface architecture / protocols for technologies such as: Industrial Internet of Things (IIoT) to support new services through interoperability and convergence with other industries; Integrated Access and Backhaul (IAB) to provide nodes for network service area extension by supporting radio 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 to simplify random access procedures (2-step RACH for NR). Standardization is also underway in system architecture / services for: 5G baseline architecture (e.g., service-based architecture or service-based interface) to combine Network Functions Virtualization (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, the already exponentially growing number of connected devices will connect to the communication network. Accordingly, enhanced functionality and performance of 5G mobile communication systems, as well as the integrated operation of connected devices, are expected to be necessary. To this end, new research is planned related to the following: extended reality (XR) for effectively supporting augmented reality (AR), virtual reality (VR), mixed reality (MR), etc.; improving 5G performance and reducing complexity by leveraging 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 serve as the foundation for developing new waveforms for providing terahertz band coverage for 6G mobile communication technologies, multi-antenna transmission technologies (such as full-dimensional MIMO (FD-MIMO), array antennas, and massive MIMO), metamaterial-based lenses and antennas for improving terahertz band signal coverage, high-dimensional spatial multiplexing technologies using orbital angular momentum (OAM), and reconfigurable intelligent surfaces (RIS), but also as the foundation for developing full-duplex technologies to improve the frequency efficiency of 6G mobile communication technologies and improve system networks, AI-based communication technologies to implement system optimization by leveraging satellites and artificial intelligence (AI) from the design stage and internalizing end-to-end AI support capabilities, and next-generation distributed computing technologies to implement services with complexity exceeding the limits of UE operational capabilities 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 determination or assertion is made regarding whether any of the above content can be used as prior art with respect to this disclosure. Summary of the Invention

[0009] Technical issues

[0010] The aspects of this disclosure at least address the aforementioned problems and / or disadvantages, and provide at least the following advantages. Accordingly, one aspect of this disclosure is to provide a solution supporting LTM with low latency, low complexity, and no user plane data loss. The embodiments are also intended to take into account the impact on conventional behavior to avoid conflicts with it.

[0011] Another aspect of this disclosure is a method for providing LTM cell handover (e.g., LTM cell handover of a secondary cell group (SCG)) support for user equipment (UE) configured with dual connectivity.

[0012] Another aspect of this disclosure is to provide several solutions for handling failures in LTM execution so as to enable rapid recovery.

[0013] Another aspect of this disclosure is to provide apparatus and methods as set forth in the appended claims.

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

[0015] Solution to the problem

[0016] According to an aspect of this disclosure, a method performed by a user equipment (UE) in a communication system is provided. The method includes: receiving a radio resource control (RRC) message including a Layer 1 (L1) / Layer 2 (L2) triggered mobility (LTM) configuration; identifying that an LTM cell handover process has been triggered; and releasing the current dedicated radio configuration associated with the cell group for which the LTM cell handover process was triggered, wherein, in the case that the LTM cell handover process is triggered on the primary cell group (MCG), the current dedicated radio configuration is released except for the MCG cell-radio network temporary identifier (C-RNTI).

[0017] In an embodiment, if LTM is triggered for MN or MCG, one of the other currently dedicated radio configurations associated with the cell group for which the LTM process is triggered includes SCG C-RNTI.

[0018] In an embodiment, if LTM is triggered for SN or SCG, the conditions for the parameters set in the RRC message and the lower layer instructions are met to trigger only the random access procedure.

[0019] In this embodiment, after the UE receives the RRCReconfiguration message, it determines whether the RRCReconfiguration message includes scg-State. If it does not, it determines whether spCellConfig in nr-SCG includes reconfigurationWihSync. If the RRCReconfiguration message is not applied because the lower layer indicates that it should skip the random access procedure for LTM cell handover, a random access procedure is initiated on PSCell.

[0020] According to another aspect of this disclosure, a user equipment (UE) in a communication system is provided, the UE including a transceiver and a processor, the processor being coupled to the transceiver and configured to: receive a radio resource control (RRC) message including a Layer 1 (L1) / Layer 2 (L2) triggered mobility (LTM) configuration associated with an LTM cell handover process; identify that an LTM cell handover process has been triggered; and release the current dedicated radio configuration associated with the cell group for which the LTM cell handover process was triggered, wherein, in the case that the LTM cell handover process is triggered on a primary cell group (MCG), the current dedicated radio configuration is released except for the MCG cell radio network temporary identifier (C-RNTI).

[0021] According to another aspect of this disclosure, a method performed by a base station in a communication system. The method includes: obtaining the configuration of an LTM associated with a Layer 1 (L1) / Layer 2 (L2) triggered mobility (LTM) cell handover procedure; and sending a Radio Resource Control (RRC) message including the configuration, wherein, in the event that the LTM cell handover procedure is triggered on a primary cell group (MCG), the current dedicated radio configuration, except for the MCG cell radio network temporary identifier (C-RNTI), is released.

[0022] According to another aspect of this disclosure, a base station in a communication system. The base station includes a transceiver and a processor coupled to the transceiver and configured to acquire a Layer 1 (L1) / Layer 2 (L2) triggered mobility (LTM) configuration associated with an LTM cell handover process, and to transmit a Radio Resource Control (RRC) message including the configuration, wherein, in the event that an LTM cell handover process is triggered on a Primary Cell Group (MCG), the current dedicated radio configuration, except for the MCG Cell Radio Network Temporary Identifier (C-RNTI), is released.

[0023] Beneficial effects of the invention

[0024] The aspects of this disclosure at least address the aforementioned problems and / or disadvantages, and provide at least the following advantages. Accordingly, one aspect of this disclosure is to provide a solution supporting LTM with low latency, low complexity, and no user plane data loss. The embodiments are also intended to take into account the impact on conventional behavior to avoid conflicts with it.

[0025] Another aspect of this disclosure is a method for providing LTM cell handover (e.g., LTM cell handover of a secondary cell group (SCG)) support for user equipment (UE) configured with dual connectivity.

[0026] Another aspect of this disclosure is to provide several solutions for handling failures in LTM execution so as to enable rapid recovery.

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

[0028] The above and other aspects, features and advantages of certain embodiments of the present disclosure will become more apparent from the following description taken in conjunction with the accompanying drawings, in which:

[0029] Figure 1 A signaling procedure for LTM according to an embodiment of the present disclosure is illustrated;

[0030] Figure 2 A network configuration according to an embodiment of the present disclosure is shown;

[0031] Figure 3 A flowchart illustrating an embodiment according to this disclosure is shown;

[0032] Figure 4 An electronic device according to an embodiment of the present disclosure is shown; and

[0033] Figure 5 A base station according to an embodiment of the present disclosure is shown.

[0034] Throughout the accompanying drawings, it should be noted that the same reference numerals are used to depict the same or similar elements, features, and structures. Detailed Implementation

[0035] The following description with reference to the accompanying drawings is intended to aid in a full understanding of the various embodiments of this disclosure as defined by the claims and their equivalents. It includes various specific details to aid understanding, but these are 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 this disclosure. Additionally, for clarity and brevity, descriptions of well-known functions and structures may be omitted.

[0036] The terms and words used in the following description and claims are not limited to their literal meaning, but are used by the inventors only to enable a clear and consistent understanding of this disclosure. Therefore, those skilled in the art should understand that the following description of various embodiments of this disclosure is for illustrative purposes only and is not intended to limit the scope of this disclosure as defined by the appended claims and their equivalents.

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

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

[0039] Any function or operation described herein can be processed by a processor or a combination of processors. A processor or combination of processors is circuitry that performs processing and includes circuitry such as an application processor (AP, e.g., a central processing unit (CPU)), a communication processor (CP, e.g., a modem), a graphics processing unit (GPU), a neural processing unit (NPU) (e.g., an artificial intelligence (AI) chip), a Wi-Fi chip, a Bluetooth chip, etc. Other related circuitry includes chips such as GPS chips, NFC chips, connectivity chips, sensor controllers, touch controllers, fingerprint sensor controllers, display driver integrated circuits (ICs), audio codec chips, universal serial bus (USB) controllers, camera controllers, image processing ICs, microprocessor units (MPUs), system-on-a-chip (SoCs), ICs, etc.

[0040] Figure 1 A signaling procedure for LTM according to an embodiment of the present disclosure is illustrated.

[0041] refer to Figure 1 The LTM process is as follows.

[0042] 1. The UE sends a MeasurementReport message to the gNB. The gNB decides to use LTM and initiates preparation of (multiple) candidate cells.

[0043] 2.gNB sends an RRCReconfiguration message to the UE, which includes the LTM candidate cell configuration of one or more candidate cells.

[0044] 3. The UE stores the LTM candidate cell configuration and sends an RRCReconfigurationComplete message to the gNB.

[0045] 4a. The UE can perform DL synchronization with (multiple) candidate cells before receiving a cell handover command. At least based on the SSB, DL synchronization of (multiple) candidate cells before a cell handover command can be supported.

[0046] 4b. Before receiving a cell handover command, the UE may perform an Early Timing Advance (TA) acquisition with the candidate cells(s) requested by the network. This is accomplished via a random access procedure (i.e., a contention-free random access procedure, CFRA) triggered by a PDCCH command from the source cell, followed by the UE sending a preamble to the indicated candidate cell. To minimize data interruption to the source cell due to CFRA toward the candidate cells(s), the UE does not receive a RAR for TA value acquisition and indicates the TA value of the candidate cell in the cell handover command. The UE does not maintain a TA timer for the candidate cells and relies on the network implementation to guarantee TA validity.

[0047] At least based on SSB, it supports the synchronization of (multiple) candidate cells before a cell handover command.

[0048] At least based on PDCCH commands, RACH supports the acquisition of TA (Timing Advance) for (multiple) candidate cells before an LTM cell handover command, where the PDCCH command is triggered only by the source cell. The source cell can trigger a UE's Random Access Procedure (RACH) to a candidate cell via PDCCH commands to obtain the candidate cell's Timing Advance or Timing Advance Value (TA). This only performs preamble transmission and does not expect to receive a Random Access Response (RAR) to simplify network and UE implementation. Specifically, preamble transmission during this RACH for TA acquisition (i.e., early RACH) can be considered a successful completion of the RACH. To reduce processing complexity, unlike a normal RACH, the UE does not need to calculate the Radio Network Temporary Identifier (RA-RNTI) for the Random Access Response before / at the time of sending the preamble. More specifically, the UE sends a preamble to the candidate cell indicated 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 the Random Access Flow (RACH) procedure for TA acquisition (i.e., Early RACH), the network can have the TA values ​​for candidate cells and know whether these TAs are still valid, for example, by maintaining a network-side timer (i.e., timeAlignmentTimer (TAT)) 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-less 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 to the UE or indicate whether the TA is still valid 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 of the target LTM candidate cell is running (i.e., the TA value is valid) or if no beam failure of the target LTM candidate cell is detected, the UE can perform LTM cell handover without a random access procedure (i.e., skip the random access procedure using a no-RACH solution). This means that the UE can listen to the PDCCH from the target LTM candidate cell, or the UE can use the configured authorization to transmit the first uplink (UL) data to the target cell for no-RACH LTM execution (LTM cell handover).

[0049] 5. The UE performs L1 measurements on the configured candidate cells and sends a lower-layer measurement report to the gNB.

[0050] 6.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.

[0051] 7. If cell handover requires the execution of a random access procedure, the UE performs a random access procedure to the target cell.

[0052] 8. The UE completes the LTM cell handover process by sending an RRCReconfigurationComplete message to the target cell. If the UE has already performed the RA procedure in step 7, 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 of the UE's C-RNTI in the target cell, which schedules new transmissions after the first UL data.

[0053] The UE can execute steps 4-8 multiple times based on the configuration provided in step 2 for subsequent LTM cell handover.

[0054] LTM cell handover procedures are primarily designed for UEs configured with a single connection (i.e., a single connection with a gNB). In New Radio (NR), due to the coexistence of LTE and NR and the high demands for data rates and low latency, it is common for UEs to be configured with dual connectivity (DC), i.e., providing the UE with two connections, with a primary cell group (MCG) or primary node (MN) and a secondary cell group (SCG) or secondary node (SN). Typically, the UE has different Radio Resource Control (RRC) procedures for the MCG and SCG respectively.

[0055] Figure 2 A general view of a network including NR-gNB and LTE eNB and associated network components and the DC configuration of the UE, according to embodiments of this disclosure, is shown.

[0056] refer to Figure 2 The radio access network for next-generation mobile communication systems (hereinafter referred to as NR or 5G) includes NR gNB or NR base station 1c-10 and new radio core network (NR CN) 1c-05, as shown in the figure. New radio user equipment (hereinafter referred to as NR UE or terminal) 1c-15 accesses external networks through NR gNB 1c-10 and NR CN 1c-05.

[0057] exist Figure 2 In 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 a radio channel and is capable of providing better service than the existing Node B. In next-generation mobile communication systems, all user services are provided through a shared channel, thus requiring a device for aggregating and scheduling state information (such as the UE's buffer state, available transmission power state, and channel state), which is handled by the NR gNB 1c-10.

[0058] A single NR gNB typically controls multiple cells. To achieve significantly higher data transmission rates compared to current LTE, next-generation mobile communication systems can have at least the maximum bandwidth currently available and can further combine beamforming technology with OFDM as a radio access technology. Furthermore, an AMC scheme is applied, which determines the modulation scheme and channel coding rate based on the UE's channel state.

[0059] The NR CN 1c-05 performs functions such as mobility support, bearer configuration, and QoS configuration. The NR CN is responsible not only for UE mobility management functions but also for various control functions and connects to multiple base stations. Furthermore, next-generation mobile communication systems can interoperate with 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.

[0060] refer to Figure 2 In embodiments of this disclosure, the UE is configured with dual connectivity, i.e., it independently supports the LTM cell handover process for both the MCG and SCG, and several solutions are described to achieve this.

[0061] First, the MCG should not participate in the SCG's LTM cell handover process to keep it simple. However, given that SCG configuration can be sent via SRB1 (i.e., the MCG), the UE should avoid triggering corresponding actions related to SCG parameters if parameters are received from the MCG. One key parameter is "reconfigurationwithsync," which automatically triggers the Random Access (RA) procedure in the SCG Media Access Control (MAC) entity. To avoid this unexpected behavior, the conditions related to LTM candidate configurations and related procedures will be discussed later.

[0062] In addition, the UE retains the MCG Cell-Radio Network Temporary Identifier (C-RNTI) during LTM cell handover for MCG, while releasing the SCG C-RNTI during LTM cell handover for SCG to save UE memory. This is because the MCG C-RNTI can be used in the event of a radio link failure (RLF) or RRC reconstruction, but it is not worthwhile to retain the SCG C-RNTI, as explained later.

[0063] The following pertains to RRC reconfiguration. The purpose of this procedure is to modify RRC connections, such as establishing / modifying / releasing RB / BH RLC channels / Uu relay RLC channels / PC5 relay RLC channels, performing reconfiguration with synchronization, establishing / modifying / releasing measurements, adding / modifying / releasing SCells and cell groups, adding / modifying / releasing conditional handover configurations, adding / modifying / releasing conditional PSCell changes or conditional PSCell addition configurations, and adding / modifying / LTM candidate cells. As part of this procedure, NAS-specific information can be transmitted from the network to the UE.

[0064] Performing RRC reconfiguration with synchronous reconfiguration includes, but is not limited to, the following:

[0065] - Reconfiguration with synchronization and security key refresh, involving RA and MAC resets, security refreshes, and RLC and PDCP reconstruction triggered by explicit L2 indicators;

[0066] - Reconfiguration with synchronization but without security key refresh, involving RA, MAC reset and RLC reconstruction of Pcell / PSCell and PDCP data recovery triggered by explicit L2 indicators (for AM DRB or AM MRB).

[0067] - Features reconfiguration for DAPS synchronization and security key refresh, involving the target Pcell's RA, target MAC establishment, and

[0068] - For non-DAPS bearers: security refresh and RLC reconstruction and PDCP triggered by explicit L2 indicators;

[0069] - For DAPS bearers: Establish RLC for the target Pcell, refresh and reconfigure PDCP for security to add encryption, integrity protection and ROHC functionality to the target Pcell;

[0070] - For SRB: Refresh security and establish RLC and PDCP for the target Pcell;

[0071] - Reconfiguration with DAPS synchronization but without security key refresh, involving the establishment of the target Pcell's RA, target MAC, and

[0072] - For non-DAPS bearers: RLC reconstruction and PDCP data recovery triggered by explicit L2 indicators (for AM DRB or AM MRB).

[0073] - For DAPS bearers: Establish RLC for the target Pcell and reconfigure PDCP to add encryption, integrity protection and ROHC functionality to the target Pcell;

[0074] - For SRB: Create RLC and PDCP for the target Pcell.

[0075] - Synchronous reconfiguration for direct-to-indirect path switching, without involving the target-side RA, involving the reconstruction of PDCP / PDCP data recovery (for AM DRB) triggered by explicit L2 indicators.

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

[0077] The network can initiate an RRC reconfiguration procedure for a UE in the RRC_CONNECTED state. The network applies this procedure as follows:

[0078] - RB establishment is performed only when AS security is activated (except for SRB1 established during RRC connection establishment).

[0079] - The establishment of the BH RLC channel for IAB is performed only when AS security has been activated;

[0080] - The establishment of Uu trunk RLC channels and PC5 trunk RLC channels (other than SL-RLC0 and SL-RLC1) for L2 U2N trunk UEs is performed only when AS security has been activated, and the establishment of PC5 trunk RLC channels (other than SL-RLC0 and SL-RLC1) for L2 U2N remote UEs is performed only when AS security has been activated.

[0081] - The addition of secondary cell groups and SCells is performed only if AS security has been activated;

[0082] - ReconfigurationWithSync is included in the secondaryCellGroup only when at least one RLC bearer or BH RLC channel is established in the SCG;

[0083] - ReconfigurationWithSync is included in masterCellGroup only if AS security has been activated and an SRB2 with at least one DRB or multicast MRB or an SRB2 for IAB has been established and not suspended.

[0084] -Conditional Reconfiguration for CPC is included only if at least one RLC bearer is established in the SCG;

[0085] -Conditional reconfiguration for CHO or CPA is included only if AS security has been activated and an SRB2 with at least one DRB or multicast MRB, or an SRB2 for IAB, has been established and is not suspended.

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

[0087] The UE should perform the following actions upon receiving an RRCReconfiguration or during a conditional reconfiguration (CHO, CPA, or CPC):

[0088] For LTM cell handover, the following section describes how to generate the RRCReconfigurationComplete message.

[0089] Option 1. The RRCReconfigurationComplete message is generated upon receiving an LTM-triggered MAC CE (LTM-triggered MAC CE) (or LTM cell handover execution), and then sent 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., without RACH)). Option 1 simplifies UE implementation because the UE cannot know in advance which cell the LTM cell handover will be performed to.

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

[0091] 1> If an LTM cell handover is triggered from a lower layer (e.g., by receiving an LTM-triggered MAC CE during a MAC entity or LTM cell handover execution), or if a target LTM candidate cell configuration is applied due to an LTM candidate cell execution (in another embodiment, a second RRCReconfigurationComplete message may be generated upon successful completion of the LTM cell handover (LTM execution)):

[0092] 2> Configure the content of the RRCReconfigurationComplete message as follows:

[0093] 3> Includes LTM candidate cell configuration / information (e.g., cell identifier, UE identifier, configuration index, or configuration identifier) ​​of the target cell indicated from the lower layer (e.g., as indicated by the LTM-triggered MAC CE).

[0094] Note: When 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 content of the target cell indicated by the LTM-triggered MAC CE.

[0095] 1> If the RRCReconfiguration message includes ltm-CandidateConfig (LTM candidate cell configuration):

[0096] 2> Perform the LTM configuration process specified in 3.3.1.3;

[0097] 1> If the RRCReconfiguration message does not include ltm-CandidateConfig (LTM candidate cell configuration), then set the content of the RRCReconfigurationComplete message as follows:

[0098] Note: When 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 content of the target cell indicated by the LTM-triggered MAC CE.

[0099] 2> If RRCReconfiguration includes a masterCellGroup containing reportUplinkTxDirectCurrent:

[0100] 3> Includes the uplinkTxDirectCurrentList for each MCG serving cell with UL;

[0101] 3> Include the uplinkDirectCurrentBWP-SUL (if any) of each MCG serving cell configured with a SUL carrier in the uplinkTxDirectCurrentList;

[0102] 2> If RRCReconfiguration includes a masterCellGroup containing reportUplinkTxDirectCurrentTwoCarrier:

[0103] 3> The uplinkTxDirectCurrentTwoCarrierList includes a list of uplink Tx DC locations for in-band uplink carrier aggregation configured in the MCG;

[0104] 2> If RRCReconfiguration includes a masterCellGroup containing reportUplinkTxDirectCurrentMoreCarrier:

[0105] 3> The uplinkTxDirectCurrentMoreCarrierList includes a list of uplink Tx DC locations for in-band uplink carrier aggregation configured in the MCG;

[0106] 2> If RRCReconfiguration includes a secondaryCellGroup containing reportUplinkTxDirectCurrent:

[0107] 3> Includes the uplinkTxDirectCurrentList for each SCG serving cell with UL;

[0108] 3> Include the uplinkDirectCurrentBWP-SUL (if any) of each SCG serving cell configured with a SUL carrier in the uplinkTxDirectCurrentList;

[0109] 2> If RRCReconfiguration includes a secondaryCellGroup containing reportUplinkTxDirectCurrentTwoCarrier:

[0110] 3> The uplinkTxDirectCurrentTwoCarrierList includes a list of uplink Tx DC locations for in-band uplink carrier aggregation configured in the SCG;

[0111] 2> If RRCReconfiguration includes a secondaryCellGroup containing reportUplinkTxDirectCurrentMoreCarrier:

[0112] 3> The uplinkTxDirectCurrentMoreCarrierList includes a list of uplink Tx DC locations for in-band uplink carrier aggregation configured in the SCG;

[0113] Note 0b: The UE does not expect to receive reportUplinkTxDirectCurrentTwoCarrier or reportUplinkTxDirectCurrentMoreCarrier in both the masterCellGroup and secondaryCellGroup. The network configures at most one of reportUplinkTxDirectCurrent, reportUplinkTxDirectCurrentTwoCarrier, or reportUplinkTxDirectCurrentMoreCarrier in a single RRC message.

[0114] 2> If the RRCReconfiguration message includes mrdc-SecondaryCellGroupConfig set to eutra-SCG:

[0115] 3> According to Clause 5.3.5.3 of TS 36.331, include the E-UTRA RRCConnectionReconfigurationComplete message in the eutra-SCG-Response;

[0116] 2> If the RRCReconfiguration message includes mrdc-SecondaryCellGroupConfig set to nr-SCG:

[0117] 3> Include the SCG RRCReconfigurationComplete message in nr-SCG-Response;

[0118] 3> If the RRCReconfiguration message is applied due to a conditional reconfiguration execution and the RRCReconfiguration message does not include the reconfigurationWithSync message in the masterCellGroup:

[0119] 4> Include the condReconfigId of the selected cell for conditional reconfiguration execution in selectedCondRRCReconfig;

[0120] 2> If RRCReconfiguration includes reconfigurationWithSync in MCG's spCellConfig:

[0121] 3> If the UE has already recorded measurements that can be used for NR, and if the RPLMN is included in the plmn-IdentityList stored in the VarLogMeasReport:

[0122] 4> Include logMeasAvailable in the RRCReconfigurationComplete message;

[0123] 4> If the Bluetooth measurement results are included in the measurements that the UE can use for NR recording:

[0124] 5> Include logMeasAvailableBT in the RRCReconfigurationComplete message;

[0125] 4> If the WLAN measurement results are included in the measurements that the UE can record for NR:

[0126] 5> Include logMeasAvailableWLAN in the RRCReconfigurationComplete message;

[0127] 3> If SigLoggedMeaType from VarLogMeasReport is included:

[0128] 4> If the T330 timer is running and the recorded measurement configuration is used for NR:

[0129] 5> Set sigLogMeasConfigAvailable to true in the RRCReconfigurationComplete message;

[0130] 4> Otherwise:

[0131] 5> If the UE has already recorded measurements that can be used for NR:

[0132] 6> In the RRCReconfigurationComplete message, set sigLogMeasConfigAvailable to false;

[0133] 3> If the UE has connection establishment failure or connection recovery failure information available in VarConnEstFailReport or VarConnEstFailReportList, and if RPLMN equals the plmn-Identity stored in at least one entry in VarConnEstFailReport or VarConnEstFailReportList:

[0134] 4> Include connEstFailInfoAvailable in the RRCReconfigurationComplete message;

[0135] 3> If the UE has radio link failure or handover failure information available in the VarRLF-Report, and if the RPLMN is included in the plmn-IdentityList stored in the VarRLF-Report; or

[0136] 3> If the UE has radio link failure or handover failure information available 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] :

[0137] 4> Include rlf-InfoAvailable in the RRCReconfigurationComplete message;

[0138] 3> If the UE is configured with successHO-Config when connecting to the source Pcell; and

[0139] 3> If the applied RRCReconfiguration is not due to a conditional reconfiguration performed during cell selection at the timer T311 runtime, as defined in 5.3.7.3:

[0140] 4> After successfully completing the random access procedure triggered by reconfigurationWithSync in spCellConfig for MCG, perform the actions determined by the successful handover report as specified in Clause 5.7.10.6;

[0141] 3> If the UE has successful handover information available in the VarSuccessHO-Report and if the RPLMN is included in the plmn-IdentityList stored in the VarSuccessHO-Report:

[0142] 4> Include successHO-InfoAvailable in the RRCReconfigurationComplete message;

[0143] 2> If the RRCReconfiguration message is received via SRB1, but not within mrdc-SecondaryCellGroup, E-UTRA RRCConnectionReconfiguration, or E-UTRARRCConnectionResume:

[0144] 3> If the UE is configured to provide measurement gap requirement information for the NR target frequency band:

[0145] 4> If the RRCReconfiguration message includes needForGapsConfigNR; or

[0146] 4> If the NeedForGapsInfoNR information has changed compared to the last time the UE reported this information:

[0147] 5> Include NeedForGapsInfoNR and set its contents as follows:

[0148] 6> Includes intraFreq-needForGap and sets the gap requirement information for in-frequency measurements for each NR serving cell;

[0149] 6> If requestedTargetBandFilterNR is configured:

[0150] 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;

[0151] 6> Otherwise:

[0152] 7> Include entries in interFreq-needForGap and set the corresponding gap requirement information for each supported NR band;

[0153] 3> If the UE is configured to provide NR target band measurement gap and NCSG requirement information:

[0154] 4> If the RRCReconfiguration message includes needForGapNCSG-ConfigNR; or

[0155] 4> If the needForGapNCSG-InfoNR information has changed compared to the last time the UE reported this information:

[0156] 5> Include NeedForGapNCSG-InfoNR and set the following:

[0157] 6> Includes intraFreq-needForNCSG, and sets the intervals for in-frequency measurements and NCSG requirement information for each NR serving cell;

[0158] 6> If requestedTargetBandFilterNCSG-NR is configured:

[0159] 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;

[0160] 6> Otherwise:

[0161] 7> Include an entry for each supported NR band in interFreq-needForNCSG and set the corresponding NCSG requirement information;

[0162] 3> If the UE is configured to provide measurement gaps and NCSG requirement information for the E UTRA target band:

[0163] 4> If the RRCReconfiguration message includes needForGapNCSG-ConfigEUTRA; or

[0164] 4> If the needForGapNCSG-InfoEUTRA information has changed compared to the last time the UE reported this information:

[0165] 5> Include NeedForGapNCSG-InfoEUTRA and set the following:

[0166] 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 for each supported E-UTRA band is included in needForNCSG-EUTRA, and the corresponding NCSG requirement information is set.

[0167] 2> If this process is initiated to generate a complete LTM candidate cell configuration:

[0168] 3> Process ends.

[0169] 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., without RACH)). Option 2 informs the network of 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.

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

[0171] 1> If an LTM cell handover is triggered from a lower layer (e.g., by receiving an LTM-triggered MAC CE during a MAC entity or LTM cell handover execution), or if a target LTM candidate cell configuration is applied due to an LTM candidate cell execution (in another embodiment, a second RRCReconfigurationComplete message may be generated upon successful completion of the LTM cell handover (LTM execution)):

[0172] 2> Configure the content of the RRCReconfigurationComplete message as follows:

[0173] 3> Includes LTM candidate cell configuration / information (e.g., cell identifier, UE identifier, configuration index, or configuration identifier) ​​of the target cell indicated from the lower layer (e.g., as indicated by the LTM-triggered MAC CE).

[0174] Note: When 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 content of the target cell indicated by the LTM-triggered MAC CE.

[0175] 1> If the RRCReconfiguration message includes ltm-CandidateConfig (LTM candidate cell configuration):

[0176] 2> Perform the LTM configuration process specified in 3.3.1.3;

[0177] 2> Configure the content of the RRCReconfigurationComplete message as follows:

[0178] Note: When 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 content of the target cell indicated by the LTM-triggered MAC CE.

[0179] 2> If RRCReconfiguration includes a masterCellGroup containing reportUplinkTxDirectCurrent:

[0180] 3> Includes the uplinkTxDirectCurrentList for each MCG serving cell with UL;

[0181] 3> Include the uplinkDirectCurrentBWP-SUL (if any) of each MCG serving cell configured with a SUL carrier in the uplinkTxDirectCurrentList;

[0182] 2> If RRCReconfiguration includes a masterCellGroup containing reportUplinkTxDirectCurrentTwoCarrier:

[0183] 3> The uplinkTxDirectCurrentTwoCarrierList includes a list of uplink Tx DC locations for in-band uplink carrier aggregation configured in the MCG;

[0184] 2> If RRCReconfiguration includes a masterCellGroup containing reportUplinkTxDirectCurrentMoreCarrier:

[0185] 3> The uplinkTxDirectCurrentMoreCarrierList includes a list of uplink Tx DC locations for in-band uplink carrier aggregation configured in the MCG;

[0186] 2> If RRCReconfiguration includes a secondaryCellGroup containing reportUplinkTxDirectCurrent:

[0187] 3> Includes the uplinkTxDirectCurrentList for each SCG serving cell with UL;

[0188] 3> Include the uplinkDirectCurrentBWP-SUL (if any) of each SCG serving cell configured with a SUL carrier in the uplinkTxDirectCurrentList;

[0189] 2> If RRCReconfiguration includes a secondaryCellGroup containing reportUplinkTxDirectCurrentTwoCarrier:

[0190] 3> The uplinkTxDirectCurrentTwoCarrierList includes a list of uplink Tx DC locations for in-band uplink carrier aggregation configured in the SCG;

[0191] 2> If RRCReconfiguration includes a secondaryCellGroup containing reportUplinkTxDirectCurrentMoreCarrier:

[0192] 3> The uplinkTxDirectCurrentMoreCarrierList includes a list of uplink Tx DC locations for in-band uplink carrier aggregation configured in the SCG;

[0193] Note 0b: The UE does not expect to receive reportUplinkTxDirectCurrentTwoCarrier or reportUplinkTxDirectCurrentMoreCarrier in both the masterCellGroup and secondaryCellGroup. The network configures at most one of reportUplinkTxDirectCurrent, reportUplinkTxDirectCurrentTwoCarrier, or reportUplinkTxDirectCurrentMoreCarrier in a single RRC message.

[0194] 2> If the RRCReconfiguration message includes mrdc-SecondaryCellGroupConfig set to eutra-SCG:

[0195] 3> According to Clause 5.3.5.3 of TS 36.331, include the E-UTRA RRCConnectionReconfigurationComplete message in the eutra-SCG-Response;

[0196] 2> If the RRCReconfiguration message includes mrdc-SecondaryCellGroupConfig set to nr-SCG:

[0197] 3> Include the SCG RRCReconfigurationComplete message in nr-SCG-Response;

[0198] 3> If the RRCReconfiguration message is applied due to a conditional reconfiguration execution and the RRCReconfiguration message does not include the reconfigurationWithSync message in the masterCellGroup:

[0199] 4> Include the condReconfigId of the selected cell for conditional reconfiguration execution in selectedCondRRCReconfig;

[0200] 2> If RRCReconfiguration includes reconfigurationWithSync in MCG's spCellConfig:

[0201] 3> If the UE has already recorded measurements that can be used for NR, and if the RPLMN is included in the plmn-IdentityList stored in the VarLogMeasReport:

[0202] 4> Include logMeasAvailable in the RRCReconfigurationComplete message;

[0203] 4> If the Bluetooth measurement results are included in the measurements that the UE can use for NR recording:

[0204] 5> Include logMeasAvailableBT in the RRCReconfigurationComplete message;

[0205] 4> If the WLAN measurement results are included in the measurements that the UE can record for NR:

[0206] 5> Include logMeasAvailableWLAN in the RRCReconfigurationComplete message;

[0207] 3> If SigLoggedMeaType from VarLogMeasReport is included:

[0208] 4> If the T330 timer is running and the recorded measurement configuration is used for NR:

[0209] 5> Set sigLogMeasConfigAvailable to true in the RRCReconfigurationComplete message;

[0210] 4> Otherwise:

[0211] 5> If the UE has already recorded measurements that can be used for NR:

[0212] 6> In the RRCReconfigurationComplete message, set sigLogMeasConfigAvailable to false;

[0213] 3> If the UE has connection establishment failure or connection recovery failure information available in VarConnEstFailReport or VarConnEstFailReportList, and if RPLMN equals the plmn-Identity stored in at least one entry in VarConnEstFailReport or VarConnEstFailReportList:

[0214] 4> Include connEstFailInfoAvailable in the RRCReconfigurationComplete message;

[0215] 3> If the UE has radio link failure or handover failure information available in the VarRLF-Report, and if the RPLMN is included in the plmn-IdentityList stored in the VarRLF-Report; or

[0216] 3> If the UE has radio link failure or handover failure information available 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 TS36.331:

[0217] 4> Include rlf-InfoAvailable in the RRCReconfigurationComplete message;

[0218] 3> If the UE is configured with successHO-Config when connecting to the source Pcell; and

[0219] 3> If the applied RRCReconfiguration is not due to a conditional reconfiguration performed during cell selection at the timer T311 runtime, as defined in 5.3.7.3:

[0220] 4> After successfully completing the random access procedure triggered by reconfigurationWithSync in spCellConfig for MCG, perform the actions determined by the successful handover report as specified in Clause 5.7.10.6;

[0221] 3> If the UE has successful handover information available in the VarSuccessHO-Report and if the RPLMN is included in the plmn-IdentityList stored in the VarSuccessHO-Report:

[0222] 4> Include successHO-InfoAvailable in the RRCReconfigurationComplete message;

[0223] 2> If the RRCReconfiguration message is received via SRB1, but not within mrdc-SecondaryCellGroup, E-UTRA RRCConnectionReconfiguration, or E-UTRARRCConnectionResume:

[0224] 3> If the UE is configured to provide measurement gap requirement information for the NR target frequency band:

[0225] 4> If the RRCReconfiguration message includes needForGapsConfigNR; or

[0226] 4> If the NeedForGapsInfoNR information has changed compared to the last time the UE reported this information:

[0227] 5> Include NeedForGapsInfoNR and set its contents as follows:

[0228] 6> Includes intraFreq-needForGap and sets the gap requirement information for in-frequency measurements for each NR serving cell;

[0229] 6> If requestedTargetBandFilterNR is configured:

[0230] 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;

[0231] 6> Otherwise:

[0232] 7> Include entries in interFreq-needForGap and set the corresponding gap requirement information for each supported NR band;

[0233] 3> If the UE is configured to provide NR target band measurement gap and NCSG requirement information:

[0234] 4> If the RRCReconfiguration message includes needForGapNCSG-ConfigNR; or

[0235] 4> If the needForGapNCSG-InfoNR information has changed compared to the last time the UE reported this information:

[0236] 5> Include NeedForGapNCSG-InfoNR and set the following:

[0237] 6> Includes intraFreq-needForNCSG, and sets the intervals for in-frequency measurements and NCSG requirement information for each NR serving cell;

[0238] 6> If requestedTargetBandFilterNCSG-NR is configured:

[0239] 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;

[0240] 6> Otherwise:

[0241] 7> Include an entry for each supported NR band in interFreq-needForNCSG and set the corresponding NCSG requirement information;

[0242] 3> If the UE is configured to provide measurement gaps and NCSG requirement information for the E UTRA target band:

[0243] 4> If the RRCReconfiguration message includes needForGapNCSG-ConfigEUTRA; or

[0244] 4> If the needForGapNCSG-InfoEUTRA information has changed compared to the last time the UE reported this information:

[0245] 5> Include NeedForGapNCSG-InfoEUTRA and set the following:

[0246] 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 for each supported E-UTRA band is included in needForNCSG-EUTRA, and the corresponding NCSG requirement information is set.

[0247] 2> If this process is initiated to generate a complete LTM candidate cell configuration:

[0248] 3> Process ends.

[0249] Option 3. Upon receiving an RRCReconfiguration, an RRCReconfigurationComplete message is generated corresponding to the RRCReconfiguration and sent to the source cell (the serving cell or the current cell from which the UE receives 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 a random access procedure is not triggered or executed upon receiving an LTM-triggered MAC CE (or LTM cell handover execution) (i.e., skipped (in the case of no RACH)), an RRCReconfigurationComplete message is not generated and is not sent to the target LTM cell. The UE can perform uplink data transmission without an RRCReconfigurationComplete message (i.e., using only user plane data). In addition to the benefits of Option 2, Option 3 also reduces signaling overhead.

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

[0251] 3> If an LTM cell handover is triggered from a lower layer (e.g., by receiving an LTM trigger MAC CE during a MAC entity or LTM cell handover execution), or if the target LTM candidate cell configuration is applied due to an LTM candidate cell execution or random access procedure being triggered (or if the lower layer (i.e., the MAC layer) indicates that a random access procedure is required for the LTM cell execution, or if the target LTM candidate cell's BFI_COUNTER >= beamFailureInstanceMaxCount, 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) is successfully completed):

[0252] 2> Configure the content of the RRCReconfigurationComplete message as follows:

[0253] 3> Includes LTM candidate cell configuration / information (e.g., cell identifier, UE identifier, configuration index, or configuration identifier) ​​of the target cell indicated from the lower layer (e.g., as indicated by the LTM-triggered MAC CE).

[0254] Note: When 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 content of the target cell indicated by the LTM-triggered MAC CE.

[0255] 1> If the RRCReconfiguration message includes ltm-CandidateConfig (LTM candidate cell configuration):

[0256] 2> Perform the LTM configuration process specified in 3.3.1.3;

[0257] 4> Configure the content of the RRCReconfigurationComplete message as follows:

[0258] Note: When 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 content of the target cell indicated by the LTM-triggered MAC CE.

[0259] 2> If RRCReconfiguration includes a masterCellGroup containing reportUplinkTxDirectCurrent:

[0260] 3> Includes the uplinkTxDirectCurrentList for each MCG serving cell with UL;

[0261] 3> Include the uplinkDirectCurrentBWP-SUL (if any) of each MCG serving cell configured with a SUL carrier in the uplinkTxDirectCurrentList;

[0262] 2> If RRCReconfiguration includes a masterCellGroup containing reportUplinkTxDirectCurrentTwoCarrier:

[0263] 3> The uplinkTxDirectCurrentTwoCarrierList includes a list of uplink Tx DC locations for in-band uplink carrier aggregation configured in the MCG;

[0264] 2> If RRCReconfiguration includes a masterCellGroup containing reportUplinkTxDirectCurrentMoreCarrier:

[0265] 3> The uplinkTxDirectCurrentMoreCarrierList includes a list of uplink Tx DC locations for in-band uplink carrier aggregation configured in the MCG;

[0266] 2> If RRCReconfiguration includes a secondaryCellGroup containing reportUplinkTxDirectCurrent:

[0267] 3> Includes the uplinkTxDirectCurrentList for each SCG serving cell with UL;

[0268] 3> Include the uplinkDirectCurrentBWP-SUL (if any) of each SCG serving cell configured with a SUL carrier in the uplinkTxDirectCurrentList;

[0269] 2> If RRCReconfiguration includes a secondaryCellGroup containing reportUplinkTxDirectCurrentTwoCarrier:

[0270] 3> The uplinkTxDirectCurrentTwoCarrierList includes a list of uplink Tx DC locations for in-band uplink carrier aggregation configured in the SCG;

[0271] 2> If RRCReconfiguration includes a secondaryCellGroup containing reportUplinkTxDirectCurrentMoreCarrier:

[0272] 3> The uplinkTxDirectCurrentMoreCarrierList includes a list of uplink Tx DC locations for in-band uplink carrier aggregation configured in the SCG;

[0273] Note 0b: The UE does not expect to receive reportUplinkTxDirectCurrentTwoCarrier or reportUplinkTxDirectCurrentMoreCarrier in both the masterCellGroup and secondaryCellGroup. The network configures at most one of reportUplinkTxDirectCurrent, reportUplinkTxDirectCurrentTwoCarrier, or reportUplinkTxDirectCurrentMoreCarrier in a single RRC message.

[0274] 2> If the RRCReconfiguration message includes mrdc-SecondaryCellGroupConfig set to eutra-SCG:

[0275] 3> According to Clause 5.3.5.3 of TS 36.331, include the E-UTRA RRCConnectionReconfigurationComplete message in the eutra-SCG-Response;

[0276] 2> If the RRCReconfiguration message includes mrdc-SecondaryCellGroupConfig set to nr-SCG:

[0277] 3> Include the SCG RRCReconfigurationComplete message in nr-SCG-Response;

[0278] 3> If the RRCReconfiguration message is applied due to a conditional reconfiguration execution and the RRCReconfiguration message does not include the reconfigurationWithSync message in the masterCellGroup:

[0279] 4> Include the condReconfigId of the selected cell for conditional reconfiguration execution in selectedCondRRCReconfig;

[0280] 2> If RRCReconfiguration includes reconfigurationWithSync in MCG's spCellConfig:

[0281] 3> If the UE has already recorded measurements that can be used for NR, and if the RPLMN is included in the plmn-IdentityList stored in the VarLogMeasReport:

[0282] 4> Include logMeasAvailable in the RRCReconfigurationComplete message;

[0283] 4> If the Bluetooth measurement results are included in the measurements that the UE can use for NR recording:

[0284] 5> Include logMeasAvailableBT in the RRCReconfigurationComplete message;

[0285] 4> If the WLAN measurement results are included in the measurements that the UE can record for NR:

[0286] 5> Include logMeasAvailableWLAN in the RRCReconfigurationComplete message;

[0287] 3> If SigLoggedMeaType from VarLogMeasReport is included:

[0288] 4> If the T330 timer is running and the recorded measurement configuration is used for NR:

[0289] 5> Set sigLogMeasConfigAvailable to true in the RRCReconfigurationComplete message;

[0290] 4> Otherwise:

[0291] 5> If the UE has already recorded measurements that can be used for NR:

[0292] 6> In the RRCReconfigurationComplete message, set sigLogMeasConfigAvailable to false;

[0293] 3> If the UE has connection establishment failure or connection recovery failure information available in VarConnEstFailReport or VarConnEstFailReportList, and if RPLMN equals the plmn-Identity stored in at least one entry in VarConnEstFailReport or VarConnEstFailReportList:

[0294] 4> Include connEstFailInfoAvailable in the RRCReconfigurationComplete message;

[0295] 3> If the UE has radio link failure or handover failure information available in the VarRLF-Report, and if the RPLMN is included in the plmn-IdentityList stored in the VarRLF-Report; or

[0296] 3> If the UE has radio link failure or handover failure information available 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] :

[0297] 4> Include rlf-InfoAvailable in the RRCReconfigurationComplete message;

[0298] 3> If the UE is configured with successHO-Config when connecting to the source Pcell; and

[0299] 3> If the applied RRCReconfiguration is not due to a conditional reconfiguration performed during cell selection at the timer T311 runtime, as defined in 5.3.7.3:

[0300] 4> After successfully completing the random access procedure triggered by reconfigurationWithSync in spCellConfig for MCG, perform the actions determined by the successful handover report as specified in Clause 5.7.10.6;

[0301] 3> If the UE has successful handover information available in the VarSuccessHO-Report and if the RPLMN is included in the plmn-IdentityList stored in the VarSuccessHO-Report:

[0302] 4> Include successHO-InfoAvailable in the RRCReconfigurationComplete message;

[0303] 2> If the RRCReconfiguration message is received via SRB1, but not within mrdc-SecondaryCellGroup, E-UTRA RRCConnectionReconfiguration, or E-UTRARRCConnectionResume:

[0304] 3> If the UE is configured to provide measurement gap requirement information for the NR target frequency band:

[0305] 4> If the RRCReconfiguration message includes needForGapsConfigNR; or

[0306] 4> If the NeedForGapsInfoNR information has changed compared to the last time the UE reported this information:

[0307] 5> Include NeedForGapsInfoNR and set its contents as follows:

[0308] 6> Includes intraFreq-needForGap and sets the gap requirement information for in-frequency measurements for each NR serving cell;

[0309] 6> If requestedTargetBandFilterNR is configured:

[0310] 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;

[0311] 6> Otherwise:

[0312] 7> Include entries in interFreq-needForGap and set the corresponding gap requirement information for each supported NR band;

[0313] 3> If the UE is configured to provide NR target band measurement gap and NCSG requirement information:

[0314] 4> If the RRCReconfiguration message includes needForGapNCSG-ConfigNR; or

[0315] 4> If the needForGapNCSG-InfoNR information has changed compared to the last time the UE reported this information:

[0316] 5> Include NeedForGapNCSG-InfoNR and set the following:

[0317] 6> Includes intraFreq-needForNCSG, and sets the intervals for in-frequency measurements and NCSG requirement information for each NR serving cell;

[0318] 6> If requestedTargetBandFilterNCSG-NR is configured:

[0319] 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;

[0320] 6> Otherwise:

[0321] 7> Include an entry for each supported NR band in interFreq-needForNCSG and set the corresponding NCSG requirement information;

[0322] 3> If the UE is configured to provide measurement gaps and NCSG requirement information for the E UTRA target band:

[0323] 4> If the RRCReconfiguration message includes needForGapNCSG-ConfigEUTRA; or

[0324] 4> If the needForGapNCSG-InfoEUTRA information has changed compared to the last time the UE reported this information:

[0325] 5> Include NeedForGapNCSG-InfoEUTRA and set the following:

[0326] 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 for each supported E-UTRA band is included in needForNCSG-EUTRA, and the corresponding NCSG requirement information is set.

[0327] 2> If this process is initiated to generate a complete LTM candidate cell configuration:

[0328] 3> Process ends.

[0329] 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 upon receiving an LTM-triggered MAC CE), an RRCReconfigurationComplete message is generated and sent to the target LTM candidate cell.

[0330] Options 1, 2, or 3 describe how the RRCReconfigurationComplete message is submitted via which SRB during LTM execution, extending to dual-connectivity scenarios (e.g., for UEs configured with both MCG and SCG). As described herein, LTM candidate cell configuration can be configured via the RRCReconfiguration message via SRB1 or separate SRB1 or SRB3. 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 LTM candidate cell configuration does not include reconfigurationWithSync to avoid handover triggered by the RRC message.

[0331] In another embodiment, the RRCReconfiguration message including LTM candidate cell configuration includes reconfigurationWithSync, but it should not trigger a random access procedure. For the MCG case, the generation of RRCReconfiguration can automatically trigger a random access procedure through cell changes. For this reason, especially for the SCG case (i.e., if an RRCReconfiguration message is received via SRB1 within an nr-SCG within the mrdc-SecondaryCellGroup (the UE in the NR-DC receives the mrdc-SecondaryCellGroup via SRB1 in RRCReconfiguration or RRCResume), if NR If the spCellConfig in the SCG includes `reconfigurationWithSync` and an `RRCReconfiguration` message is applied due to an LTM cell handover execution, a random access procedure is not initiated on the PSCell. For example, if `scg-State` is not included in an `RRCReconfiguration` or `RRCResume` message containing an `RRCReconfiguration` message, and if `reconfigurationWithSync` is included in the spCellConfig in the nr-SCG, and if an `RRCReconfiguration` message is not applied due to an LTM cell handover execution, the UE initiates a random access procedure on the PSCell. In another example, if `scg-State` is not included in an `RRCReconfiguration` or `RRCResume` message containing an `RRCReconfiguration` message, and if `reconfigurationWithSync` is included in the spCellConfig in the nr-SCG, and if an `RRCReconfiguration` message is not applied due to an LTM cell handover execution that instructs the lower layer to skip the random access procedure, the UE initiates a random access procedure on the PSCell.

[0332] A UE configured with single connectivity (i.e., MCG only) or without dual connectivity (i.e., MCG and SCG or MCG) can configure 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 via SRB1 to the source serving cell (primary gNB, i.e., MCG), where SRB1 sends 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 for the target LTM cell of the 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. This second RRCReconfigurationComplete contains content (e.g., the configuration ID or information of the target LTM configuration, or a reply or confirmation) and sends it 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.

[0333] In addition, submit the first RRCReconfigurationComplete as follows (which can also be applied to UEs configured with dual connectivity):

[0334] 1> If the UE is configured with E-UTRA nr-SecondaryCellGroupConfig (UE in (NG)EN-DC):

[0335] 2> Submit the first RRCReconfigurationComplete via E-UTRA;

[0336] 1> Otherwise, if the first RRCReconfiguration message is received via SRB3 (UE in NR-DC):

[0337] 2> If the first RRCReconfiguration message is received within DLInformationTransferMRDC:

[0338] 3> If the first RRCReconfiguration message (NR SCG RRC reconfiguration) is received in nr-SCG within mrdc-SecondaryCellGroup:

[0339] 4> Perform SCG reconfiguration accordingly:

[0340] 3> Otherwise (e.g., the first RRCReconfiguration message is received within the primary cell group configuration (NR MCG RRCReconfiguration):

[0341] 4> Submit the first RRCReconfigurationComplete message to the lower layer via SRB1 to transmit with the new configuration;

[0342] 2> Otherwise:

[0343] 3> Submit the first RRCReconfigurationComplete message to the lower layer via SRB3 to transmit with the new configuration;

[0344] 1> Otherwise (receiving the first RRCReconfiguration via SRB1):

[0345] 2> The first RRCReconfigurationComplete message is submitted to the lower layer via SRB1 to transmit with the new configuration;

[0346] A UE configured with dual connectivity (i.e., MCG and SCG) can configure 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.

[0347] For each case of a dual-connection, the second RRCReconfigurationComplete is submitted as follows.

[0348] If the UE has configured 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 performing 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 the UE has configured an E-UTRA nr-SecondaryCellGroupConfig (UE in (NG)EN-DC), the UE submits the second RRCReconfigurationComplete via E-UTRA. In another embodiment, the second RRCReconfigurationComplete message may be generated upon successful completion of the LTM cell handover (LTM execution).

[0349] If the UE has configured 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 performing 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 the SCG's LTM candidate configuration) is received via SRB1 in the nr-SCG within the mrdc-SecondaryCellGroup (the UE is in the NR-DC, and the mrdc-SecondaryCellGroup is received via SRB1 in RRCReconfiguration or RRCResume), the UE submits the second RRCReconfigurationComplete message via the NR MCG embedded in the NR RRC message ULInformationTransferMRDC (e.g., via SRB1 (or via a separate SRB1) to the SCG or MCG). In another embodiment, a second RRCReconfigurationComplete message may be generated when the LTM cell handover (LTM execution) is successfully completed.

[0350] If the UE is configured to receive via SRB3 (UE in NR-DC), and if an RRCReconfiguration message (or LTM candidate configuration of SCG) is received within DLInformationTransferMRDC, and if an RRCReconfiguration message is not received within nr-SCG within mrdc-SecondaryCellGroup (i.e., it is not NR SCG RRC reconfiguration), or if the target LTM candidate cell configuration of SCG is configured, 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 performing LTM cell handover in SCG), or if the target LTM candidate cell configuration of SCG is applied due to LTM candidate cell execution, then the UE generates a second RRCReconfigurationComplete message. Then, if the RRCReconfiguration message (or the LTM candidate configuration of the SCG) is an LTM candidate configuration received within the primary cell group configuration (i.e., it is the NR MCG RRCReconfiguration), the UE submits a second RRCReconfigurationComplete message to the lower layer via SRB1 for transmission with the new configuration, because DLInformationTransferMRDC includes configurations from the MCG that need to be sent to the MCG via SRB1. In another embodiment, a second RRCReconfigurationComplete message can be generated upon successful completion of the LTM cell handover (LTM execution).

[0351] If the UE has configured 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 performing 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 via SRB3 (UE in 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, since this configuration corresponds to the SCG and needs to be sent to the SCG via SRB3. In another embodiment, the second RRCReconfigurationComplete message can be generated upon successful completion of the LTM cell handover (LTM execution).

[0352] If the UE has configured 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 performing an LTM cell handover within 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 an RRCReconfigurationComplete message to the lower layer via SRB1 for transmission using the new configuration. In another embodiment, the second RRCReconfigurationComplete message may be generated upon successful completion of the LTM cell handover (LTM execution).

[0353] To achieve the above details, 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):

[0354] If the LTM cell handover is triggered from a lower layer (e.g., by receiving LTM in a MAC entity to trigger MAC CE or LTM cell handover execution), or if the target LTM candidate cell configuration is applied due to LTM candidate cell execution:

[0355] 2> Configure the content of the second RRCReconfigurationComplete message as follows:

[0356] 3> Includes LTM candidate cell configuration / information (e.g., cell identifier, UE identifier, configuration index, or configuration identifier) ​​of the target cell indicated from the lower layer (e.g., as indicated by the LTM-triggered MAC CE).

[0357] 3> If the RRCReconfiguration message includes mrdc-SecondaryCellGroupConfig set to nr-SCG:

[0358] 4> Include the SCG RRCReconfigurationComplete message in nr-SCG-Response;

[0359] 4> If the RRCReconfiguration message is applied due to a conditional reconfiguration execution and the RRCReconfiguration message does not include reconfigurationWithSync in the masterCellGroup:

[0360] 5> Include the condReconfigId of the selected cell for conditional reconfiguration execution in selectedCondRRCReconfig;

[0361] 4> - If RRCReconfiguration (or target LTM candidate configuration) is applied due to the execution of an LTM candidate cell for LTM cell handover (e.g., triggered by the reception of the first MAC CE), the LTM cell handover can be configured via the LTM candidate cell configuration contained in the nr-SCG within the mrdc-SecondaryCellGroup:

[0362] 5> The selected LTM candidate configuration includes the configuration identifier (ID) of the selected LTM candidate cell for LTM execution. The configuration ID may be indicated by the first MAC CE;

[0363] To simplify the network implementation for handling the second RRCReconfigurationComplete message, the second RRCReconfigurationComplete is submitted as follows:

[0364] 1> If the UE is configured with E-UTRA nr-SecondaryCellGroupConfig (UE in (NG)EN-DC):

[0365] 2> Submit the second RRCReconfigurationComplete via E-UTRA;

[0366] 1> Otherwise, if an RRCReconfiguration message (or target LTM candidate configuration) is received via SRB1 within an nr-SCG in the mrdc-SecondaryCellGroup (for UEs in NR-DC, receiving the mrdc-SecondaryCellGroup via SRB1 in RRCReconfiguration or RRCResume):

[0367] 2> If RRCReconfiguration is applied due to conditional reconfiguration of the CPC configured via conditionalReconfiguration contained in nr-SCG within mrdc-SecondaryCellGroup; or

[0368] 2> If RRCReconfiguration (or the target LTM candidate configuration) is applied due to an LTM cell handover (e.g., triggered by the reception of the first MAC CE) performed by an LTM candidate cell that can be configured via the LTM candidate cell configuration contained in the nr-SCG within the mrdc-SecondaryCellGroup):

[0369] 3> Submit a second RRCReconfigurationComplete message via the NR MCG embedded in the NR RRC message ULInformationTransferMRDC (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 IABOtherInformation message).

[0370] 1> Otherwise, if an RRCReconfiguration message (or target LTM candidate configuration) is received via SRB3 (UE in NR-DC):

[0371] 2> If an RRCReconfiguration message (or target LTM candidate configuration) is received within DLInformationTransferMRDC:

[0372] 3> If an RRCReconfiguration message (NR SCG RRC reconfiguration) is received in nr-SCG within mrdc-SecondaryCellGroup:

[0373] 4> Perform SCG reconfiguration accordingly:

[0374] 3> Otherwise (e.g., if the target LTM candidate configuration is received within the primary cell group configuration (NR MCG RRCReconfiguration):

[0375] 4> Submit the second RRCReconfigurationComplete message to the lower layer via SRB1 to transmit with the new configuration;

[0376] 2> Otherwise:

[0377] 3> Submit the second RRCReconfigurationComplete message to the lower layer via SRB3 to transmit with the new configuration;

[0378] 1> Otherwise (receiving RRCReconfiguration (or target LTM candidate configuration) via SRB1):

[0379] 2> Submit the second RRCReconfigurationComplete message to the lower layer via SRB1 to transmit with the new configuration;

[0380] The DLInformationTransferMRDC message is used for downlink transmission via RRC messages from SRB3 during Fast MCG link recovery, while the ULInformationTransferMRDC message is used for uplink transmission via MR-DC dedicated information from 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).

[0381] In another embodiment, a UE configured with dual connectivity (i.e., MCG and SCG) can configure 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.

[0382] For each case of a dual-connection, the second RRCReconfigurationComplete is submitted as follows.

[0383] If the UE has configured 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's MAC entity or performing an LTM cell handover within the MCG), or if a target LTM candidate cell configuration for the MCG 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 MCG) is received via SRB1, the UE submits an RRCReconfigurationComplete message to the lower layer via SRB1 for transmission using the new configuration. In another embodiment, the second RRCReconfigurationComplete message may be generated upon successful completion of the LTM cell handover (LTM execution).

[0384] If the UE has configured 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 performing 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 the SCG's LTM candidate configuration) is received via SRB1 in the nr-SCG within the mrdc-SecondaryCellGroup (the UE is in the NR-DC, and the mrdc-SecondaryCellGroup is received via SRB1 in RRCReconfiguration or RRCResume), the UE submits the second RRCReconfigurationComplete message via the NR MCG embedded in the NR RRC message ULInformationTransferMRDC (e.g., via SRB1 (or via a separate SRB1) to the SCG or MCG). In another embodiment, a second RRCReconfigurationComplete message may be generated when the LTM cell handover (LTM execution) is successfully completed.

[0385] If the UE has configured 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 from the SCG in the SCG's MAC entity to trigger a MAC CE or performing 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 via SRB3 (the UE in the NR-DC), and if no RRCReconfiguration message (or an LTM candidate configuration for the SCG) is received within DLInformationTransferMRDC, the UE submits a second RRCReconfigurationComplete message to the lower layer via SRB3 to transmit with the new configuration, since this configuration corresponds to the SCG, which 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.

[0386] If the UE has configured 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 performing an LTM cell handover within 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 an RRCReconfigurationComplete message to the lower layer via SRB1 for transmission using the new configuration. In another embodiment, the second RRCReconfigurationComplete message may be generated upon successful completion of the LTM cell handover (LTM execution).

[0387] In another embodiment, a UE configured with dual connectivity (i.e., MCG and SCG) can configure 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.

[0388] For each case of a dual-connection, the second RRCReconfigurationComplete is submitted as follows.

[0389] If the UE has configured 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 performing 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 execution of an LTM candidate cell, the UE generates a second RRCReconfigurationComplete message.

[0390] 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).

[0391] 1> If the UE is in (NG) EN-DC:

[0392] 2> If SRB3 is configured or SCG is not deactivated:

[0393] 3> The second RRCReconfigurationComplete is submitted to the lower layer via SRB3 for transmission, at which point the process ends;

[0394] 2> Otherwise:

[0395] 3> Submit the second RRCReconfigurationComplete via E-UTRA embedded in the E-UTRA RRC message ULInformationTransferMRDC.

[0396] 1> Otherwise, if the UE is in NR-DC:

[0397] 2> If the LTM candidate cell configuration is associated with SCG:

[0398] 3> If SRB3 is configured or SCG is not deactivated:

[0399] 4> The second RRCReconfigurationComplete is submitted to the lower layer via SRB3 for transmission, at which point the process ends;

[0400] 3> Otherwise:

[0401] 4> Submit the second RRCReconfigurationComplete via SRB1 embedded in the NR RRC message ULInformationTransferMRDC;

[0402] 2> Otherwise:

[0403] 3> The second RRCReconfigurationComplete is submitted to the lower layer via SRB1 for transmission, at which point the process ends;

[0404] 1> Otherwise (i.e., the UE is configured with a single connection):

[0405] 2> Submit the second RRCReconfigurationComplete to the lower layer for transmission, at which point the process ends.

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

[0407] In embodiments of this disclosure, the LTM configuration of a candidate cell can indicate a reference configuration or a complete configuration of the LTM candidate cell. The reference configuration can be the complete configuration, or the reference configuration and the LTM candidate cell-specific configuration can be the complete configuration of the LTM candidate cell.

[0408] 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) of the source cell, or to avoid data transmission to the target cell during random access. After successful 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.

[0409] The UE should perform the following actions based on the received LTM-CandidateConfig IE:

[0410] 1> Store the received ltm-ReferenceConfiguration in VarLTM-Config (if it exists);

[0411] 1> If LTM-CandidateConfig includes ltm-CandidateToReleaseList:

[0412] 2> Execute LTM candidate cell release;

[0413] 1> If LTM-CandidateConfig includes ltm-CandidateToAddModList:

[0414] 2> Perform LTM candidate cell addition or reconfiguration;

[0415] 1> Perform actions to generate a complete LTM configuration;

[0416] Note X: The UE implements a method to defer the generation of the complete LTM configuration until LTM cell handover is performed.

[0417] The following pertains to LTM candidate cell release. The UE should:

[0418] 1> For each ltm-CandidateId in ltm-CandidateToReleaseList:

[0419] 2> If the current VarLTM-Config includes LTM candidates with a given LTM-CandidateId:

[0420] 3> Release LTM candidates from VarLTM-Config;

[0421] The LTM candidate cell configuration can be automatically released by the UE (or can be released via an explicit indicator in a received RRC message) under the following conditions:

[0422] - When LTM execution (or LTM cell handover) is successfully completed

[0423] - Upon receiving the RRC Release message (because LTM execution is only available in RRC connection state).

[0424] - If RRCSetup is received in response to RRCReestablishmentRequest (because this means that the UE failed to perform 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.

[0425] 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 it upon receiving an RCRelease message indicating a transition to RRC inactive mode, and can reconfigure or use it to restore the RRC connection with the RCResume message. For example, the RCRelease message indicating a transition to RRC inactive mode 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.

[0426] The following pertains to adding / modifying LTM candidate cells. The UE should:

[0427] 1> For each ltm-CandidateId in ltm-CandidateToAddModList:

[0428] 2> If the current VarLTM-Config includes LTM candidates with a given LTM-CandidateId:

[0429] 3> Modify the LTM candidates in VarLTM-Config according to the received LTM candidates;

[0430] 2> Otherwise:

[0431] 3> Add the received LTM candidates to the VarLTM configuration.

[0432] The following pertains to the generation of the UE LTM configuration. The purpose of this process is to enable 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 target cell's LTM candidate cell configuration indicated by the lower layer only when the lower layer receives an LTM cell handover indication (i.e., as indicated by an LTM trigger MAC CE). The current UE configuration should not be modified during the generation of the complete LTM candidate cell configuration.

[0433] UE should:

[0434] 1> For each ltm-Candidate in ltm-CandidateConfigList within VarLTM-Config;

[0435] 2> Store the ltm-CandidateId included in ltm-Candidate within VarLTM-UE-Config;

[0436] 2> If ltm-Candidate includes ltm-ConfigComplete;

[0437] 3> Generate a complete LTM candidate cell configuration based on the received LTM candidates according to the action, and store it in ue-LTM-Config within VARLTM-UE-Config.

[0438] 2> Otherwise:

[0439] 3> Generate a complete LTM candidate cell configuration by applying ltm-Candidate on top of referenceConfiguration based on the action, and store it in ue-LTM-Config within VarLTM-UE-Config.

[0440] The following pertains to LTM cell handover execution. When a lower-layer indication triggers an LTM cell handover procedure, the UE should:

[0441] 1>Release / clear all current dedicated radio configurations except for the following:

[0442] 2> If LTM cell handover is triggered on the MCG:

[0443] -MCG C-RNTI; When the lower layer indicates that an LTM cell handover process is triggered on the MCG, the UE needs to maintain or retain the MCG C-RNTI because the UE can use the RNTI during the RLF or RRC reconstruction process, which can occur during the LTM scell handover process.

[0444] - AS security configuration associated with the master key;

[0445] 2> Otherwise, if LTM cell handover is triggered on the SCG:

[0446] - The UE does not need to retain the SCG C-RNTI because there is no use case for this RNTI during the LTM scell handover process. (That is, the UE discards (or releases or clears) the SCG C-RNTI when the lower layer indicates that an LTM cell handover process is triggered on the SCG.)

[0447] - AS security configuration associated with the secondary key;

[0448] - SRB1 / SRB2 configuration and DRB configuration configured by radioBearerConfig or RadioBearerConfig 2;

[0449] -UE variables VarLTM-Config and VARLTM-UE-Config

[0450] 1> Release / clear all current public radio configurations associated with the cell group that triggered the LTM cell handover procedure;

[0451] 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;

[0452] 1> Apply the default L1 parameter values ​​specified in the corresponding physical layer specification, except for the following:

[0453] - Parameters whose values ​​are provided in SIB1 (i.e., system information);

[0454] 1> Based on the LTM candidate cell configuration associated with the LTM candidate cell configuration identifier received from the lower layer, apply the value of newUE-Identity as the C-RNTI for this cell group;

[0455] 1> Configure the lower layer according to the LTM candidate cell configuration indicated by the lower layer, based on the received spCellConfigCommon;

[0456] 1> Configure the lower layer according to the LTM candidate cell configuration indicated by the lower layer, based on the received rach-ConfigDedicated.

[0457] 1> Configure a PDCP entity for LTM candidate cells indicated by the lower layer, which has continuous state variables for SRB and the same security configuration as the PDCP entity for the source cell group;

[0458] 1> Stop the corresponding SpCell timer T310 (if it is running);

[0459] 1> If this procedure is performed for MCG:

[0460] 2> If timer T316 is running;

[0461] 3> Stop timer T316;

[0462] 1> Stop the timer T312 for the corresponding SpCell (if it is running);

[0463] 1> Start the timer for the supervisory timer (i.e., T3xx) of this cell group, where the timer value is set to the configuration value in RRCReconfiguration, such as the value included in the ltm-Timers field;

[0464] 1> Reset the MAC entity of this cell group;

[0465] 1> Apply the specified BCCH configuration to the target LTM candidate cell configuration;

[0466] 1> If applicable, obtain the MIB of the target SpCell indicated in the LTM candidate cell configuration indicated by the lower layer;

[0467] 1> Apply the LTM configuration in UE-LTM-Config within VarLTM-UE-Config, which is related to the LTM candidate cell configuration identifier received from the lower layer.

[0468] 1> If the value of the ltm-NoResetID field contained in the LTM candidate IE associated with the LTM candidate cell configuration identifier (target configuration ID) received by the lower layer (i.e., the MAC layer) is equal to the value of ltm-ServingCellNoResetID in VarLTM-ServingCellNoResetID:

[0469] 2> Continue using the current RLC entity in the LTM candidate cell configuration indicated by the lower layer;

[0470] 2> Replace the value of ltm-ServingCellNoResetID in VarLTM-ServingCellNoResetID with the value received in ltm-NoResetID;

[0471] 1> Otherwise:

[0472] 2> For each RLC-BearerConfig within rlc-BearerToAddModList that is part of the current UE configuration:

[0473] 3> Reconstruct the RLC entity;

[0474] 2> For each drb-Identity value included in drb-ToAddModList, which is part of the current UE configuration:

[0475] 3> Trigger the PDCP entity of this DRB to perform data recovery;

[0476] 2> Replace the value of ltm-ServingCellNoResetID in VarLTM-ServingCellNoResetID with the value received in ltm-NoResetID;

[0477] 1> Continue to use the current PDCP entity in the LTM candidate cell configuration (target configuration ID) indicated by the lower layer (i.e., MAC layer); 1> Apply the LTM configuration in ue-LTM-Config within VarLTM-UE-Config associated with the LTM candidate cell configuration identifier received from the lower layer;

[0478] 1> Treat LTM candidate cells indicated by lower layers as serving cells;

[0479] 1> If an RRCReconfiguration message containing an LTM candidate IE associated with the LTM candidate cell configuration identifier (target configuration ID) received by the SRB1 in the nr-SCG within the mrdc-SecondaryCellGroup (UE in NR-DC):

[0480] 2> Submit the RRCReconfigurationComplete message via the NR MCG embedded in the NR RRC message ULInformationTransferMRDC;

[0481] 1> Otherwise, if the UE receives an RRCReconfiguration message via SRB3 (in NR-DC) containing an LTM candidate IE associated with the LTM candidate cell configuration identifier received from the lower layer:

[0482] 2> Submit the RRCReconfigurationComplete message to the lower layer via SRB3 to transmit with the new configuration;

[0483] 1> Otherwise (received via SRB1, RRCReconfiguration):

[0484] 2> Submit the RRCReconfigurationComplete message to the lower layer so that the new configuration can be transmitted via SRB1.

[0485] 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), an LTM execution procedure can be initiated in either the MCG or SCG. However, note 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 of the MCG failure experienced by the UE, i.e., MCG radio link failure. The network reports this to the MCG by sending an RRC message (i.e., MCG failure information message) via the SCG (i.e., via separate SRB1 or SRB3). UEs in the RRC_CONNECTED state (for those that have already utilized SRB2 and at least one DRB or multicast MRB settings, or have activated AS security for IAB, SRB2) can initiate a fast MCG link recovery procedure to continue the RRC connection without rebuilding. When neither MCG nor SCG transmissions are suspended, the SCG is not deactivated, T316 is configured, and a radio link failure of the MCG is detected while the T316 is not running, a UE configured with a separate SRB1 or SRB3 can initiate this procedure to report an MCG failure. When notifying the MCG of an MCG failure, the MCG can send an RRC release message via the SCG (i.e., via a separate SRB1 or SRB3), an RRC reconfiguration message with reconfigurationwithSync (i.e., handover indication) for the PCell, or a MobilityFromNRCommand message to release or restore the RRC connection.

[0486] Timer T316 can only be configured if the UE has a detached SRB1 or SRB3 configured. 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 detached SRB, the UE submits the MCG failure information message to the lower layer for transmission via SRB1. Otherwise (i.e., if SRB3 is configured), the UE submits the MCG failure information message to the lower layer via SRB3 for transmission embedded in the NR RRC message ULInformationTransferMRDC. The UE stops timer T316 upon receiving an RRC release message, an RRC reconfiguration message with reconfigurationwithSync (i.e., handover indication) for the PCell, a MobilityFromNRCommand message, or after initiating an RRC reconstruction procedure. When timer T316 expires, the UE initiates an RRC reconstruction procedure.

[0487] Considering the MCG failure recovery process described above, if T316 is running, it means that an MCG failure has already occurred. Therefore, it is important to carefully consider the scenario where LTM cell handover is initiated while T316 is running. To effectively handle this situation, the following options exist. One of these options can be implemented to perform LTM execution.

[0488] Option 1: In this option, if the UE receives the first MAC CE during T316 operation 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.

[0489] When the lower-level instruction triggers the LTM cell handover process, the UE should:

[0490] 1>Release / clear all current dedicated radio configurations except for the following:

[0491] 2> If LTM cell handover is triggered on the MCG:

[0492] -MCG C-RNTI; When the lower layer indicates that an LTM cell handover process is triggered on the MCG, the UE needs to maintain or retain the MCG C-RNTI because the UE can use the RNTI during the RLF or RRC reconstruction process, which can occur during the LTM scell handover process.

[0493] - AS security configuration associated with the master key;

[0494] 2> Otherwise, if LTM cell handover is triggered on the SCG:

[0495] The UE does not need to retain the SCG C-RNTI because there is no use case for this RNTI during the LTM scell handover process. (That is, the UE discards (or releases or clears) the SCG C-RNTI when the lower layer indicates that an LTM cell handover process is triggered on the SCG) - AS security configuration associated with the secondary key;

[0496] - SRB1 / SRB2 configuration and DRB configuration configured by radioBearerConfig or RadioBearerConfig 2;

[0497] -UE variables VarLTM-Config and VARLTM-UE-Config

[0498] 1> Release / clear all current public radio configurations associated with the cell group that triggered the LTM cell handover procedure;

[0499] 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;

[0500] 1> Apply the default L1 parameter values ​​specified in the corresponding physical layer specification, except for the following:

[0501] - Parameters whose values ​​are provided in SIB1 (i.e., system information);

[0502] 1> Based on the LTM candidate cell configuration associated with the LTM candidate cell configuration identifier received from the lower layer, apply the value of newUE-Identity as the C-RNTI for this cell group;

[0503] 1> Configure the lower layer according to the LTM candidate cell configuration indicated by the lower layer, based on the received spCellConfigCommon;

[0504] 1> Configure the lower layer according to the LTM candidate cell configuration indicated by the lower layer, based on the received rach-ConfigDedicated.

[0505] 1> Configure a PDCP entity for LTM candidate cells indicated by the lower layer, which has continuous state variables for SRB and the same security configuration as the PDCP entity for the source cell group;

[0506] 1> Stop the corresponding SpCell timer T310 (if it is running);

[0507] 1> If this procedure is performed on MCG:

[0508] 2> If timer T316 is running;

[0509] 3> Stop timer T316;

[0510] 1> Stop the timer T312 for the corresponding SpCell (if it is running);

[0511] 1> Start the timer for the supervisory timer (i.e., T3xx) of this cell group, where the timer value is set to the configuration value in RRCReconfiguration, such as the value included in the ltm-Timers field;

[0512] 1> Reset the MAC entity of this cell group;

[0513] 1> Apply the specified BCCH configuration to the target LTM candidate cell configuration;

[0514] 1> If applicable, obtain the MIB of the target SpCell indicated in the LTM candidate cell configuration indicated by the lower layer;

[0515] 1> Apply the LTM configuration in UE-LTM-Config within VarLTM-UE-Config, which is related to the LTM candidate cell configuration identifier received from the lower layer.

[0516] 1> If the value of the ltm-NoResetID field contained in the LTM candidate IE associated with the LTM candidate cell configuration identifier (target configuration ID) received by the lower layer (i.e., the MAC layer) is equal to the value of ltm-ServingCellNoResetID in VarLTM-ServingCellNoResetID:

[0517] 2> Continue using the current RLC entity in the LTM candidate cell configuration indicated by the lower layer;

[0518] 2> Replace the value of ltm-ServingCellNoResetID in VarLTM-ServingCellNoResetID with the value received in ltm-NoResetID;

[0519] 1> Otherwise:

[0520] 2> For each RLC-BearerConfig within rlc-BearerToAddModList that is part of the current UE configuration:

[0521] 3> Reconstruct the RLC entity;

[0522] 2> For each drb-Identity value included in drb-ToAddModList, which is part of the current UE configuration:

[0523] 3> Trigger the PDCP entity of this DRB to perform data recovery;

[0524] 2> Replace the value of ltm-ServingCellNoResetID in VarLTM-ServingCellNoResetID with the value received in ltm-NoResetID;

[0525] 1> Continue to use the current PDCP entity in the LTM candidate cell configuration (target configuration ID) indicated by the lower layer (i.e., MAC layer); 1> Apply the LTM configuration in ue-LTM-Config within VarLTM-UE-Config associated with the LTM candidate cell configuration identifier received from the lower layer;

[0526] 1> Treat LTM candidate cells indicated by lower layers as serving cells;

[0527] 1> If an RRCReconfiguration message (in the NR-DC) containing an LTM candidate IE associated with the LTM candidate cell configuration identifier (target configuration ID) received by the SRB1 in the nr-SCG within the mrdc-SecondaryCellGroup is received:

[0528] 2> Submit the RRCReconfigurationComplete message via the NR MCG embedded in the NR RRC message ULInformationTransferMRDC;

[0529] 1> Otherwise, if an RRCReconfiguration message (in the UE in NR-DC) containing an LTM candidate IE associated with the LTM candidate cell configuration identifier received from the lower layer is received via SRB3:

[0530] 2> Submit the RRCReconfigurationComplete message to the lower layer via SRB3 to transmit with the new configuration;

[0531] 1> Otherwise (received via SRB1, RRCReconfiguration):

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

[0533] Option 2: In this option, if the UE receives the first MAC CE during T316 operation 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. Note that LTM cell handover can be performed within a cell group. When 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.

[0534] When the lower layer indicates that the LTM cell handover process is triggered, if T316 is not running (when T316 is not running), the UE should:

[0535] 1>Release / clear all current dedicated radio configurations except for the following:

[0536] 2> If LTM cell handover is triggered on the MCG:

[0537] -MCG C-RNTI; When the lower layer indicates that an LTM cell handover process is triggered on the MCG, the UE needs to maintain or retain the MCG C-RNTI because the UE can use the RNTI during the RLF or RRC reconstruction process, which can occur during the LTM scell handover process.

[0538] - AS security configuration associated with the master key;

[0539] 2> Otherwise, if LTM cell handover is triggered on the SCG:

[0540] The UE does not need to retain the SCG C-RNTI because there is no use case for this RNTI during the LTM scell handover process. (That is, the UE discards (or releases or clears) the SCG C-RNTI when the lower layer indicates that an LTM cell handover process is triggered on the SCG) - AS security configuration associated with the secondary key;

[0541] - SRB1 / SRB2 configuration and DRB configuration configured by radioBearerConfig or RadioBearerConfig 2;

[0542] -UE variables VarLTM-Config and VARLTM-UE-Config

[0543] 1> Release / clear all current public radio configurations associated with the cell group that triggered the LTM cell handover procedure;

[0544] 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;

[0545] 1> Apply the default L1 parameter values ​​specified in the corresponding physical layer specification, except for the following:

[0546] - Parameters whose values ​​are provided in SIB1 (i.e., system information);

[0547] 1> Based on the LTM candidate cell configuration associated with the LTM candidate cell configuration identifier received from the lower layer, apply the value of newUE-Identity as the C-RNTI for this cell group;

[0548] 1> Configure the lower layer according to the LTM candidate cell configuration indicated by the lower layer, based on the received spCellConfigCommon;

[0549] 1> Configure the lower layer according to the LTM candidate cell configuration indicated by the lower layer, based on the received rach-ConfigDedicated.

[0550] 1> Configure a PDCP entity for LTM candidate cells indicated by the lower layer, which has continuous state variables for SRB and the same security configuration as the PDCP entity for the source cell group;

[0551] 1> Stop the corresponding SpCell timer T310 (if it is running);

[0552] 1> If this procedure is performed for MCG:

[0553] 2> If timer T316 is running;

[0554] 3> Stop timer T316;

[0555] 1> Stop the timer T312 for the corresponding SpCell (if it is running);

[0556] 1> Start the timer for the supervisory timer (i.e., T3xx) of this cell group, where the timer value is set to the configuration value in RRCReconfiguration, such as the value included in the ltm-Timers field;

[0557] 1> Reset the MAC entity of this cell group;

[0558] 1> Apply the specified BCCH configuration to the target LTM candidate cell configuration;

[0559] 1> If applicable, obtain the MIB of the target SpCell indicated in the LTM candidate cell configuration indicated by the lower layer;

[0560] 1> Apply the LTM configuration in UE-LTM-Config within VarLTM-UE-Config, which is related to the LTM candidate cell configuration identifier received from the lower layer.

[0561] 1> If the value of the ltm-NoResetID field contained in the LTM candidate IE associated with the LTM candidate cell configuration identifier (target configuration ID) received by the lower layer (i.e., the MAC layer) is equal to the value of ltm-ServingCellNoResetID in VarLTM-ServingCellNoResetID:

[0562] 2> Continue using the current RLC entity in the LTM candidate cell configuration indicated by the lower layer;

[0563] 2> Replace the value of ltm-ServingCellNoResetID in VarLTM-ServingCellNoResetID with the value received in ltm-NoResetID;

[0564] 1> Otherwise:

[0565] 2> For each RLC-BearerConfig within rlc-BearerToAddModList that is part of the current UE configuration:

[0566] 3> Reconstruct the RLC entity;

[0567] 2> For each drb-Identity value included in drb-ToAddModList, which is part of the current UE configuration:

[0568] 3> Trigger the PDCP entity of this DRB to perform data recovery;

[0569] 2> Replace the value of ltm-ServingCellNoResetID in VarLTM-ServingCellNoResetID with the value received in ltm-NoResetID;

[0570] 1> Continue to use the current PDCP entity in the LTM candidate cell configuration (target configuration ID) indicated by the lower layer (i.e., MAC layer); 1> Apply the LTM configuration in ue-LTM-Config within VarLTM-UE-Config associated with the LTM candidate cell configuration identifier received from the lower layer;

[0571] 1> Treat LTM candidate cells indicated by lower layers as serving cells;

[0572] 1> If an RRCReconfiguration message containing an LTM candidate IE associated with the LTM candidate cell configuration identifier (target configuration ID) received by the SRB1 in the nr-SCG within the mrdc-SecondaryCellGroup (UE in NR-DC):

[0573] 2> Submit the RRCReconfigurationComplete message via the NR MCG embedded in the NR RRC message ULInformationTransferMRDC;

[0574] 1> Otherwise, if the UE receives an RRCReconfiguration message via SRB3 (in NR-DC) containing an LTM candidate IE associated with the LTM candidate cell configuration identifier received from the lower layer:

[0575] 2> Submit the RRCReconfigurationComplete message to the lower layer via SRB3 to transmit with the new configuration;

[0576] 1> Otherwise (received via SRB1, RRCReconfiguration):

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

[0578] For the above options, the UE can stop T310 and T312 when initiating LTM execution, as these timers are used to listen to the radio link. For example, the UE can start T310 when it detects a physical layer problem in the SpCell (i.e., when it receives a pre-configured number of consecutive asynchronous indications from the lower layer), and stop it when it receives a number of consecutive synchronization indications from the lower layer of the SpCell, 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 rebuild procedure, when a conditional reconfiguration execution is performed (i.e., when a stored RRCReconfiguration message including reconfigurationWithSync is applied for the cell group), when it initiates an MCG failure information procedure, and when it performs an LTM cell handover execution. For example, if T312 is configured in the MCG, when triggering a measurement report for a measurement identifier that has been configured with T312 and whose useT312 value has been set to true, when T310 in the PCell is running, the UE initiates T312, and when receiving a pre-configured number of continuous synchronization indications from the lower layer of the SpCell, when receiving an RRCReconfiguration with reconfigurationWithSync for the cell group, when receiving a MobilityFromNRCommand, when initiating an RRC reconstruction procedure, or in the rlf-TimersAndConstant... The UE stops T312 when reconfiguring, during the MCG failure information process, during conditional reconfiguration (i.e., when a stored RRCReconfiguration message including reconfigurationWithSync is applied to the cell group), when T310 in the corresponding SpCell expires, when the SCG is released, if T312 is retained in the SCG, if T312 is configured in the SCG and useT312 has been set to true, when a measurement report is triggered for a measurement identifier that has been configured with T312, or during LTM cell handover, or when T310 in the PSCell is running.

[0579] Figure 3 A flowchart illustrating a method according to an embodiment of the present disclosure is shown.

[0580] In operation S101, the UR communicatively connects to the primary node MN or primary cell group MCG and the secondary node SN or secondary cell group SCG in a dual-connectivity DC configuration. In operation S102, it is determined whether LTM was triggered for MN / MCG or SN / SCG.

[0581] If triggered for MN / MCG, in operation S103, the UE maintains the MCG cell-radio network temporary identifier C-RNTI and clears or releases other current private radio configurations associated with the cell group for which the LTM procedure was triggered.

[0582] If triggered for SN / SCG, in operation S104, the UE clears or releases the current private radio configuration associated with the cell group for which the LTM procedure was triggered.

[0583] According to an embodiment, a method is provided for performing L1 / L2 triggered mobility (LTM) in a user equipment (UE), the UE being communicatively connected to a primary node (MN) or primary cell group (MCG) and a secondary node (SN) or secondary cell group (SCG) in a dual connectivity (DC) configuration, wherein: if LTM is triggered for the MN or MCG, the UE maintains the MCG cell-radio network temporary identifier (C-RNTI) and clears or releases other current dedicated radio configurations associated with the cell group for which the LTM procedure was triggered; or, if LTM is triggered for the SN or SCG, the UE clears or releases the current dedicated radio configurations associated with the cell group for which the LTM procedure was triggered.

[0584] According to an embodiment, if LTM is triggered for MN or MCG, one of the other current dedicated radio configurations associated with the cell group for which the LTM process is triggered includes SCG C-RNTI.

[0585] According to an embodiment, if LTM is triggered for SN or SCG, the conditions of the parameters set in the RRC message and the lower-level instructions are met to trigger only the random access procedure.

[0586] According to the embodiment, after the UE receives the RRCReconfiguration message, it determines whether the RRCReconfiguration message includes scg-State. If it does not include scg-State, it determines whether spCellConfig in nr-SCG includes reconfigurationWihSync. If the RRCReconfiguration message is not applied because the lower layer indicates that it should skip the random access procedure for LTM cell handover, a random access procedure is initiated on PSCell.

[0587] According to an embodiment, a method performed by a user equipment (UE) in a communication system is provided.

[0588] According to an embodiment, the method includes: receiving a Radio Resource Control (RRC) message, the RRC message including the configuration of an LTM associated with a LTM cell handover process triggered by a Layer 1 / Layer 2 (L1 / L2) process; identifying that an LTM cell handover process has been triggered; and releasing the current dedicated radio configuration associated with the cell group for which the LTM cell handover process was triggered.

[0589] According to an embodiment, when an LTM cell handover process is triggered on the primary cell group (MCG), the current dedicated radio configuration, except for the MCG cell radio network temporary identifier (C-RNTI), is released.

[0590] According to an embodiment, when an LTM cell handover process is triggered on the MCG, the current private radio configuration, in addition to the access stratum (AS) security configuration associated with the master key, is further released.

[0591] According to an embodiment, when the LTM cell handover process is triggered on the secondary cell group (SCG), the released current dedicated radio configuration includes the SCG C-RNTI.

[0592] According to an embodiment, when an LTM cell handover process is triggered on the SCG, the current private radio configuration, except for the AS security configuration associated with the secondary key, is released.

[0593] According to an embodiment, the RRC message is an RRCReconfiguration message.

[0594] According to an embodiment, a random access procedure on the primary and secondary cell (PSCell) is initiated when the RRCReconfiguration message does not include scg-State, the spCellConfig in nr-SCG includes reconfigurationWithSync, and the RRCReconfiguration message is not applied because the lower layer performs an LTM cell handover that indicates skipping the random access procedure.

[0595] Figure 4 An electronic device according to an embodiment of the present disclosure is shown.

[0596] refer to Figure 4 Electronic device 400 may include processor 410, transceiver 420, and memory 430. However, not all components shown are required. Electronic device 400 may be composed of more than Figure 4The components shown can be implemented with more or fewer components. Alternatively, according to another embodiment, the processor 410, transceiver 420, and memory 430 can be implemented as a single chip.

[0597] Electronic device 400 may correspond to the aforementioned UE.

[0598] The aforementioned components will now be described in detail.

[0599] Processor 410 may include one or more processors or other processing devices that control the proposed functions, processes, and / or methods. Operation of electronic device 400 may be implemented by processor 410.

[0600] Transceiver 420 may include an RF transmitter for up-converting and amplifying the transmitted signal, and an RF receiver for down-converting the frequency of the received signal. However, according to another embodiment, transceiver 420 may be implemented with more or fewer components than those shown in the components.

[0601] Transceiver 420 can be connected to processor 410 and send and / or receive signals. These signals may include control information and data. Additionally, transceiver 420 can receive signals via a wireless channel and output signals to processor 410. Transceiver 420 can also transmit signals output from processor 410 via a wireless channel.

[0602] Memory 430 may store control information or data included in signals acquired by electronic device 400. Memory 430 may be connected to processor 410 and store at least one instruction, protocol, or parameter for the proposed function, process, and / or method. Memory 430 may include read-only memory (ROM) and / or random access memory (RAM) and / or hard disk and / or CD-ROM and / or digital versatile disc (DVD) and / or other storage devices.

[0603] Figure 5 A base station according to an embodiment of the present disclosure is shown.

[0604] refer to Figure 5 Base station 500 may include processor 510, transceiver 520, and memory 530. However, not all of the components shown are required. Base station 500 may be composed of... Figure 5 The components shown can be implemented with more or fewer components. Alternatively, according to another embodiment, the processor 510, transceiver 520, and memory 530 can be implemented as a single chip.

[0605] Base station 500 can correspond to the gNB mentioned above.

[0606] The aforementioned components will now be described in detail.

[0607] Processor 510 may include one or more processors or other processing devices that control the proposed functions, processes, and / or methods. Operation of base station 500 may be implemented by processor 510.

[0608] Transceiver 520 may include an RF transmitter for up-converting and amplifying the transmitted signal, and an RF receiver for down-converting the frequency of the received signal. However, according to another embodiment, transceiver 520 may be implemented with more or fewer components than those shown in the components.

[0609] Transceiver 520 can be connected to processor 510 and send and / or receive signals. These signals may include control information and data. Additionally, transceiver 520 can receive signals via a wireless channel and output signals to processor 510. Transceiver 520 can also transmit signals output from processor 510 via a wireless channel.

[0610] The memory 530 may store control information or data included in signals obtained by the base station 500. The memory 530 may be connected to the processor 510 and store at least one instruction, protocol, or parameter for the proposed function, process, and / or method. The memory 530 may include read-only memory (ROM) and / or random access memory (RAM) and / or hard disk and / or CD-ROM and / or DVD and / or other storage devices.

[0611] At least some of the example embodiments described herein can be constructed, in part or in whole, using dedicated special-purpose hardware. Terms such as “component,” “module,” or “unit” as used herein can include, but are not limited to, hardware devices that perform certain tasks or provide related functions, such as circuits in discrete or integrated component form, field-programmable gate arrays (FPGAs), or application-specific integrated circuits (ASICs). In some embodiments, the described elements can be configured to reside on a tangible, persistent, addressable storage medium and can be configured to execute on one or more processors. In some embodiments, these functional elements can include, for example, components (such as software components, object-oriented software components, class components, and task components), processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. Although example embodiments have been described with reference to the components, modules, and units discussed herein, such functional elements can be combined into fewer elements or separated into additional elements. Various combinations of optional features have been described herein, and it should be understood that the described features can be combined in any suitable combination. In particular, features of any example embodiment can be appropriately combined with features of any other embodiment, unless such combinations are mutually exclusive. Throughout this specification, the terms "comprising" or "comprises" mean that the specified components are included, but do not exclude the presence of other components.

[0612] Please note all papers and documents related to this application that were submitted concurrently with or prior to this specification and are made publicly available along with this specification. The contents of all such papers and documents are incorporated herein by reference.

[0613] All features disclosed in this specification (including any appended claims, abstract, and drawings) and / or all steps of any method or process so disclosed may be combined in any combination except for at least some mutually exclusive combinations of such features and / or steps.

[0614] Unless otherwise expressly stated, each feature disclosed in this specification (including any appended claims, abstract, and drawings) may be replaced by an alternative feature for the same, equivalent, or similar purpose. Therefore, unless otherwise expressly stated, each disclosed feature is merely one example of a series of equivalent or similar features.

[0615] While this disclosure has been shown and described with reference to various embodiments thereof, those skilled in the art will understand that various changes in form and detail may be made therein without departing from the spirit and scope of this disclosure as defined by the appended claims and their equivalents.

Claims

1. A method performed by a user equipment (UE) in a communication system, the method comprising: Receive Radio Resource Control (RRC) messages, which include LTM configurations associated with a mobility LTM cell handover process triggered by Layer 1 L1 / Layer 2 L2. The LTM cell handover process was identified as being triggered; and Release the current dedicated radio configuration associated with the cell group that triggered the LTM cell handover procedure. In cases where the LTM cell handover process is triggered on the primary cell group (MCG), the current dedicated radio configuration, except for the MCG cell radio network temporary identifier (C-RNTI), is released.

2. The method according to claim 1, wherein, When an LTM cell handover process is triggered on the MCG, the current private radio configuration, in addition to the access layer AS security configuration associated with the master key, is released.

3. The method according to claim 1, wherein, When an LTM cell handover process is triggered on the secondary cell group (SCG), the released current dedicated radio configuration includes the SCG C-RNTI.

4. The method according to claim 1, wherein, When an LTM cell handover process is triggered on a secondary cell group (SCG), the current private radio configuration, except for the access stratum AS security configuration associated with the secondary key, is released.

5. The method according to claim 1, in, The RRC message is the RRCReconfiguration message, and In the case where the secondary cell group SCG state is not included in the RRCReconfiguration message, reconfigurationWithSync is included in spCellConfig in nr-SCG, and the RRCReconfiguration message is not applied because the lower layer indicates that the LTM cell handover to skip the random access procedure is executed, the random access procedure on the primary and secondary cell PSCell is initiated.

6. A user equipment (UE) in a communication system, the UE comprising: transceiver; and A processor, coupled to the transceiver, is configured to: Receive Radio Resource Control (RRC) messages, which include LTM configurations associated with a mobility LTM cell handover process triggered by Layer 1 L1 / Layer 2 L2. The LTM cell handover process was identified as being triggered; and Release the current dedicated radio configuration associated with the cell group that triggered the LTM cell handover procedure. In cases where the LTM cell handover process is triggered on the primary cell group (MCG), the current dedicated radio configuration, except for the MCG cell radio network temporary identifier (C-RNTI), is released.

7. The UE according to claim 6, wherein, When an LTM cell handover process is triggered on the MCG, the current private radio configuration, in addition to the access layer AS security configuration associated with the master key, is released.

8. The UE according to claim 6, wherein, When an LTM cell handover process is triggered on the secondary cell group (SCG), the released current dedicated radio configuration includes the SCG C-RNTI.

9. The UE according to claim 6, wherein, When an LTM cell handover process is triggered on a secondary cell group (SCG), the current private radio configuration, except for the access stratum AS security configuration associated with the secondary key, is released.

10. The UE according to claim 6, in, The RRC message is the RRCReconfiguration message, and In the case where the secondary cell group SCG state is not included in the RRCReconfiguration message, reconfigurationWithSync is included in spCellConfig in nr-SCG, and the RRCReconfiguration message is not applied because the lower layer indicates that the LTM cell handover to skip the random access procedure is executed, the random access procedure on the primary and secondary cell PSCell is initiated.

11. A method performed by a base station in a communication system, the method comprising: Obtain the LTM configuration associated with the L1 / L2 mobility LTM cell handover process triggered by Layer 1 L1 / Layer 2 L2; and Send a Radio Resource Control (RRC) message including the configuration. In cases where the LTM cell handover process is triggered on the primary cell group (MCG), the current dedicated radio configuration, except for the MCG cell radio network temporary identifier (C-RNTI), is released.

12. The method according to claim 11, wherein, When an LTM cell handover process is triggered on the MCG, the current private radio configuration, in addition to the access layer AS security configuration associated with the master key, is released.

13. The method according to claim 11, wherein, When an LTM cell handover process is triggered on the secondary cell group (SCG), the released current dedicated radio configuration includes the SCG C-RNTI.

14. A base station in a communication system, the base station comprising: transceiver; and A processor, coupled to the transceiver, is configured to: Obtain the LTM configuration associated with the L1 / L2 mobility LTM cell handover process triggered by Layer 1 L1 / Layer 2 L2; and Send a Radio Resource Control (RRC) message including the configuration. In cases where the LTM cell handover process is triggered on the primary cell group (MCG), the current dedicated radio configuration, except for the MCG cell radio network temporary identifier (C-RNTI), is released.

15. The base station according to claim 14, wherein, When an LTM cell handover process is triggered on the MCG, the current private radio configuration, in addition to the access layer AS security configuration associated with the master key, is released.

Images